fix up comment

Added a comment: Confirming all annexed files exist elsewhere?

Added a comment: Bump for --want-get/drop-by

use ResourcePool for hash-object handles

Avoid starting an unncessary number of git hash-object processes when
concurrency is enabled.

Sponsored-by: Dartmouth College's DANDI project

analysis

comment and fix my incorrect earlier comment

Merge branch 'master' of ssh://git-annex.branchable.com

handle upgrading repositories initialized with --version=9

There is nothing in upgrade.log because it was never upgraded to version
9. Before, it would have never autoupgraded to 10, but it's entirely
safe to upgrade to 10 immediately.

Of course, annex.autoupgraderepository = false will prevent that
upgrade. So if someone for some reason really wants v9, they can set
that. I can't think of a reason someone would actually want v9 rather
than v10 though.

Sponsored-by: k0ld on Patreon

v8 repositories automatically upgrade to v9

(And v9 later on to v10.)

When v9/v10 were added, making v8 automatically upgrade was deferred
"for a few months" to prevent interoperability problems if users also
have an old version of git-annex. Of course that could still be the
case, but there has been a good amount of time and this can't be put off
forever.

Allow setting annex.autoupgraderepository to false to avoid this upgrade.
Previously, that only prevented upgrades from no longer supported git-annex
versions, but v8 is still supported, and users may want to keep on v8 to
interoperate with an old git-annex version.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

avoid writing new line to upgrade.log when upgrade is deferred

With automatic upgrades to v10 enabled, this could have led to each
run of git-annex adding a line to upgrade.log for v9. However,
they're not yet, so it only happened when running git-annex upgrade
in a v9 repository.

Sponsored-by: Brock Spratlen on Patreon

fix logic errors in code that determines if it's time for v10 upgrade

This would have prevented old git-annex from ever upgrading from v9 to
v10. Note that a manual `git-annex upgrade` can never run while the
assistant is running, so not <$> assistantrunning was always True,
so no matter what the timestamp of the v9 upgrade in the log, it would
decide there was old process danger.

Sponsored-by: Jack Hill on Patreon

initial report on hash-object's

Added a comment

fix build

add news item for git-annex 10.20220724

releasing package git-annex version 10.20220724

comment

comment

comment

Added a comment

removed

Added a comment

Added a comment

Added a comment

Added a comment: Confirmed your suspiction

Added a comment

close git bug that I reported to git mailing list

reproduced

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

force fully strict read of journal file again

I was thinking that discardIncompleteAppend would make it strict, since
it looks at the end of the bytestring. But, it's applied lazily..

This probably fixes windows, which was failing:

      git-annex.exe: .git\annex\journal\trust.log: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\5\\tmprepo22\\.git\\annex\\journal\\trust.log": permission denied (The process cannot access the file because it is being used by another process.)

Added a comment

Added a comment

Added a comment: Happens only when core.untrackedCache=true

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

fixed

Merge branch 'append'

prevent appends except when annex.alwayscompact=false

I would like for a new repo version to enable appends, but to do so
safely would need a v11 followed by a 1 year delay followed by a v12
that does it. Since a similar v9 and v10 transition is currently
happening, and is less than 6 months along in most repos, it does not
feel wise to stack up another year-long transition behind that. What if
I need to hurry up a new repo version for some other change?

Added todo so I remember to make this change at some time when a v11
and probably v12 repo version do make sense.

Sponsored-by: Dartmouth College's DANDI project

handling of interrupted appends

An append that is interrupted and writes part of a line is now dealt
with by subsequent reads and appends. This also handles a read that
happens at the same time as an append to the file.

Old versions of git-annex will still see a partially written line,
and could get confused. Since appends are currently done for url logs
and location logs, the confusion is limited to a substring of the actual
url or UUID of the remote being read. This will not affect writes, since
the journal file is locked when reading in preparation for writing.
However, the bad data can be output by git-annex and used by other
things, or could cause surprising behavior by git-annex. Including eg,
downloading the content of the wrong url.

So, something needs to be done to prevent old versions of git-annex from
running in a repository where this appending is being done..

Sponsored-by: Dartmouth College's DANDI project

no locking of journal on read after all

Finally have a final design, and it turns out not to need locking on read.

comment

Added a comment

thoughts

Added a comment: cannot reproduce

comment

comment

Merge branch 'master' into append

fix build

After 28b0aaea54e9515c16e440f9f22688dc2e7dc642

re-add lock journal before reading journal files

This reverts commit 2e6e9876e3fc420a22eee82eedec54ac3f678878.

This is gonna be needed after all.. The append will only be atomic if
the journal is locked, because the file being appended will have to be
moved out of the way to avoid an old version of git-annex seeing an
incomplete write to it. When git-annex finds that the file is not in the
journal, and checks the append location, locking will be needed to avoid
a race causing it to miss it in the append location too due to it being
moved back to the journal.

add annex.alwayscompact

Added annex.alwayscompact setting which can be unset to speed up writes to
the git-annex branch in some cases.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

comments

Merge branch 'master' into append

efficient but unsafe journal file append

This is only for checking performance, it's not safe.

Sponsored-by: Dartmouth College's DANDI project

minor optimisation

Avoid re-writing the file when the journal directory did not
exist.

Revert "lock journal before reading journal files"

This reverts commit 47358a6f956681346a198cdf27c60bcf9498cc45.

This added overhead, and will not be needed, because appends are going
to have to be made atomic for other reasons than avoiding incomplete
reads of data being appended.

In particular, when git-annex is interrupted in the middle of an append,
it must not leave the file with a partially written line. So appending
has to somehow be made fully atomic.

split out appending to journal from writing, high level only

Currently this is not an improvement, but it allows for optimising
appendJournalFile later. With an optimised appendJournalFile, this will
greatly speed up access patterns like git-annex addurl of a lot of urls
to the same key, where the log file can grow rather large. Appending
rather than re-writing the journal file for each line can save a lot of
disk writes.

It still has to read the current journal or branch file, to check
if it can append to it, and so when the journal file does not exist yet,
it can write the old content from the branch to it. Probably the re-reads
are better cached by the filesystem than repeated writes. (If the
re-reads turn out to keep performance bad, they could be eliminated, at
the cost of not being able to compact the log when replacing old
information in it. That could be enabled by a switch.)

While the immediate need is to affect addurl writes, it was implemented
at the level of presence logs, so will also perhaps speed up location logs.
The only added overhead is the call to isNewInfo, which only needs to
compare ByteStrings. Helping to balance that out, it avoids compactLog
when it's able to append.

Sponsored-by: Dartmouth College's DANDI project

added suggestion to record ETags in URL- keys

removed duplicated content

Merge branch 'master' into append

Add new bug "creating failure getting/copying on git-lfs remote (gcrypt)"

Add new bug "creating failure getting/copying on git-lfs remote (gcrypt)"

Added a comment: checksums and addurl --fast

Added a comment

Added a comment

Added a comment

Added a comment: Hashes for files added via addurl

increase cabal-version to work with recent cabal

It started complaining about custom setup needing too old a version of
cabal, a very confusing error message.

1.12 is the version of Cabal on the i386ancient builder.

Sponsored-by: Jack Hill on Patreon

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

design work

lock journal before reading journal files

This is not currently necessary; journal files are updated atomically.

However, for faster appends to large journal files, locking on read will
be needed, because appends are not atomic.

Sponsored-by: Dartmouth College's DANDI project

disable journalIgnorable in enableInteractiveBranchAccess

Fix a reversion that prevented --batch commands (and the assistant)
from noticing data written to the journal by other commands.

I have not identified which commit broke this for sure,
but probably it was aeca7c2207a652c8a72f044204a5c0edb4782aac

--batch commands that wrote to the journal avoided the problem since
journalIgnorable sets unset on write. It's a little bit surprising that
nobody noticed that query --batch commands did not see data written by
other commands.

Sponsored-by: Dartmouth College's DANDI project

complete a comment

Added a comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment

comment

Added a comment

comments

S3: Avoid writing or checking the uuid file in the S3 bucket when importtree=yes or exporttree=yes

It does not make sense for either; importing from an existing bucket should
not write to it. And the user may not have write access at all. And exporting to
a bucket should not write other files.

Also this prevents the uuid file being imported after being written.

Sponsored-by: Dartmouth College's DANDI project

comment

close

comment

Added a comment

Added a comment