comment

close wontfix

document another behavior of --auto

add a test case for transition propagation

As was fixed in 6992250d63484a6cf3e5d22b9137d23a3fe1a63e.
It took 2-3 years to notice that bug, so this part of git-annex needs
test cases like this.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

fix obviously wrong attoparsec parser

takeByteString can only be used at the end of a parser, not before other
input. This was a dumb enough mistake that I audited the rest of the
code base for similar mistakes. Pity that attoparsec cannot avoid it at
the type level.

Fixes git-annex forget propagation between repositories. (reversion
introduced in version 7.20190122)

Sponsored-by: Brock Spratlen on Patreon

bug report followup

comment

comment

comment

comment and bug report

comment

Added a comment

removed

Added a comment

Added a comment

Added a comment

added question on git-annex memory usage

Pass --no-textconv when running git diff internally

Seems that --no-ext-diff and -c diff.external= are not enough to disable
external diff command when gitattributes textconv specifies it.

I'm pretty sure that --no-ext-diff and -c diff.external= are not both
needed, but not 100%. Something about -G may need the latter to fully
disable diffs in some cases. So kept that part as it was.

Sponsored-by: Dartmouth College's Datalad project

comment

comment

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

comment

adb: Avoid find failing with "Argument list too long"

The "+" argument only runs the command once, so is not safe to use. Using
";" instead would have been the simplest fix, but also the slowest.

Since my phone has an xargs that supports -0, I piped find to xargs
instead. Unsure how portable this will be, perhaps some android's don't
have xargs -0 or find -printf to send null terminated output.

The business with pipefail is necessary to make a failure of find cause the
import to fail. Probably this works on all androids, but if not, it will
probably just result in a failure of find being ignored. It would be
possible to make ignorefinderror just disable setting pipefail, but then
if some android has a shell that has pipefail enabled by default, ignorefinderror
would not work, so I kept the || true approach for that.

Sponsored-by: Max Thoursie on Patreon

comment

Added a comment: conda updated

Added a comment

Added a comment

Added a comment: Thanks!

add news item for git-annex 10.20220127

releasing package git-annex version 10.20220127

improve display of subframes

update

comment

Added a comment: comment regarding "default" version of the repo etc

comment

clarify --version behavior on upgrade

eg, git-annex init --version=9 does not use v10 even though v9 can
automatically upgrade to v10, because v9 is a supported version. It's
only unsupported versions that make a newer version be used.

have v9 autoupgrade to v10

This was right before commit a27776f6026082683ab40d88745f1cc6242fca6c,
which made v6 v7 autoupgrade to v8 but not yet to v10.

Sponsored-by: Dartmouth College's Datalad project

reject batch options combined with non-batch options

Reject combinations of --batch (or --batch-keys) with options like --all or
--key or with filenames.

Most commands ignored the non-batch items when batch mode was enabled.

For some reason, addurl and dropkey both processed first the specified
non-batch items, followed by entering batch mode. Changed them to also
error out, for consistency.

Sponsored-by: Dartmouth College's Datalad project

comment

initial whining about --batch-keys and --all

Added a comment

comment

Added a comment

init --version=6 upgrade to 8 not yet 10

autoUpgradeableVersions had latestVersion (10), but it did not make
sense for asking for old version 6 to get version 10, while asking for
version 8 got version 8. So use defaultVersion (8) instead.

Sponsored-by: Dartmouth College's Datalad project

add question

comment

close; out of scope

comment

comment

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

clarify

initial report about autoupgrade to 10 instead of 8

fix name of option

deal with which being deprecated in Debian

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

fix failing readonly test case

The problem is that withContentLockFile, in a v8 repo, has to take a shared
lock of `.git/annex/content.lck`. But, in a readonly repository, if that
file does not yet exist, it cannot lock it. And while it will sometimes
work to `chmod +r .git/annex`, the repository might be readonly due to
being owned by another user, or due to being mounted readonly.

So, it seems that the only solution is to use some other file than
`.git/annex/content.lck` as the lock file. The inode sential file
was almost the only option that should always exist. (And if it somehow
does not exist, creating an empty one for locking will be ok.)

Wow, what a hack!

Sponsored-by: Dartmouth College's Datalad project

update

don't fail git-annex upgrade to v10

That left the repo in v8, but with filter.annex.process set. Instead,
only warn, and defer the v10 upgrade.

Sponsored-by: Dartmouth College's Datalad project

enable filter.annex.process in v9

This has tradeoffs, but is generally a win, and users who it causes git add to
slow down unacceptably for can just disable it again.

It needed to happen in an upgrade, since there are git-annex versions
that do not support it, and using such an old version with a v8
repository with filter.annex.process set will cause bad behavior.
By enabling it in v9, it's guaranteed that any git-annex version that
can use the repository does support it. Although, this is not a perfect
protection against problems, since an old git-annex version, if it's
used with a v9 repository, will cause git add to try to run
git-annex filter-process, which will fail. But at least, the user is
unlikely to have an old git-annex in path if they are using a v9
repository, since it won't work in that repository.

Sponsored-by: Dartmouth College's Datalad project

close

detect v10 upgrade while running

Capstone of the v10 upgrade process.

Tested with a git-annex drop in a v8 repo that had a local v8 remote.
Upgrading the repo to v10 (with --force) immedaitely caused it to notice
and switch over to v10 locking. Upgrading the remote also caused it to
switch over when operating on the remote.

The InodeCache makes this fairly efficient, just an added stat call per
lock of an object file. After the v10 upgrade, there is no more
overhead.

Sponsored-by: Dartmouth College's Datalad project

update, v9 upgrade not yet automatic

and v9 does not have full upgrade locking

update for v10

Sponsored-by: Dartmouth College's Datalad project

fix crash after drop in v10

After cleaning up the lock file, the content directory is gone, so
freezing it failed.

Sponsored-by: Dartmouth College's Datalad project

continue to use v8 by default for now, unless upgraded

Since it's easy to keep supporting v8, using it for a while (eg a few
months) will give users time to upgrade git-annex installations, before
it upgrades their repository to v9.

This commit should be reverted once ready to start upgrading
repositories by default.

Sponsored-by: Dartmouth College's Datalad project

prevent manual git-annex upgrade to v10 when unsafe

Allow --force

Sponsored-by: Dartmouth College's Datalad project

automatic upgrade from v8 to v9

Sponsored-by: Dartmouth College's Datalad project

v10 upgrade locking

The v10 upgrade should almost be safe now. What remains to be done is
notice when the v10 upgrade has occurred, while holding the shared lock,
and switch to using v10 lock files.

Sponsored-by: Dartmouth College's Datalad project

update on status

add upgrade.log

The upgrade from V9 uses this to avoid an automatic upgrade until 1 year
after the V9 update. It can also be used in future such situations.

Sponsored-by: Dartmouth College's Datalad project

split upgrade into v9 and v10

v10 will run 1 year after the upgrade to v9, to give time for any v8
processes to die. Until that point, the v10 upgrade will be tried by
every process but deferred, so added support for deferring upgrades.

The upgrade prevention lock file that will be used by v10 is not yet
implemented, so it does not yet defer.

Sponsored-by: Dartmouth College's Datalad project

fix spelling of upgradeable

Merge branch 'master' into v9-locking

commeent

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

close

Added a comment: Now it's working normally again

Added a comment: nested git repositories are git submodules

delete content lock file safely after shared lock

Upgrade the shared lock to an exclusive lock, and then delete the
lock file. If there is another process still holding the shared lock,
the first process will fail taking the exclusive lock, and not delete
the lock file; then the other process will later delete it.

Note that, in the time period where the exclusive lock is held, other
attempts to lock the content in place would fail. This is unlikely to be
a problem since it's a short period.

Other attempts to lock the content for removal would also fail in that
time period, but that's no different than a removal failing because
content is locked to prevent removal.

Sponsored-by: Dartmouth College's Datalad project

clean empty object directories after deleting content lock file

When dropping content, this was already done after deleting the content
file, but the lock file prevents deleting the directories. So, try the
deletion again.

This does mean there's a small added overhead of a failed rmdir().

Sponsored-by: Dartmouth College's Datalad project

Added a comment

fix logic that was not inverted after all

oops

Added a comment

delete content lock file safely on drop, keep after shared lock

This seems to be the best that can be done to avoid forever accumulating
the new content lock files, while being fully safe.

This is fixing code paths that have lingered unused since direct mode!
And direct mode seems to have been buggy in this area, since the content
lock file was deleted on unlock. But with a shared lock, there could be
another process that also had the lock file locked, and deleting it
invalidates that lock.

So, the lock file cannot be deleted after a shared lock. At least, not
wihout taking an exclusive lock first.. which I have not pursued yet but may.

After an exclusive lock, the lock file can be deleted. But there is
still a potential race, where the exclusive lock is held, and another
process gets the file open, just as the exclusive lock is dropped and
the lock file is deleted. That other process would be left with a file
handle it can take a shared lock of, but with no effect since the file
is deleted. Annex.Transfer also deletes lock files, and deals with this
same problem by using checkSaneLock, which is how I've dealt with it
here.

Sponsored-by: Dartmouth College's Datalad project

fix inverted logic

Now the content lock files are used in v9. However, I am not yet certian
they are correct. In particular, lockContentUsing deletes
the content lock file on unlock. But what if there's a shared lock
by another process? That seems like it would discard that lock too!

(Windows seems like it would not have the same problem, because as the
comment in there says, "Can't delete a locked file on Windows".
So if another process has a shared lock, removing it presumably fails.)

Sponsored-by: Dartmouth College's Datalad project

v9 upgrade implemented

Seems to work ok. Unsure yet about the actual locking changes being
correct.

This is not the end of the story with upgrades, because it is unsafe for
this upgrade as implemented to run in a repository where an old
git-annex process is already running. The old process would use the old
locking method, and not notice files locked by the new, and this could
result in data loss. This problem will need to be dealt with before this
branch is suitable for merging.

Sponsored-by: Dartmouth College's Datalad project

move code from Command.Fsck

Sponsored-by: Dartmouth College's Datalad project

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

liking this solution pretty well

Added a comment