move verifyKeyContent to Annex.Verify

The goal is that Database.Keys be able to use it; it can't use
Annex.Content.Presence due to an import loop.

Several other things also needed to be moved to Annex.Verify as a
conseqence.

comment

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

fix potential race in updating inode cache

Some uses of linkFromAnnex are inside replaceWorkTreeFile, which was
already safe, but others use it directly on the work tree file, which
was race-prone. Eg, if the work tree file was first removed, then
linkFromAnnex called to populate it, the user could have re-written it in
the interim.

This came to light during an audit of all calls of addInodeCaches,
looking for such races. All the other uses of it seem ok.

Sponsored-by: Brett Eisenberg on Patreon

fix potential race in updating inode cache

In Annex.Content, the object file was statted after pointer files were
populated. But if annex.thin is set, once the pointer files are
populated, the object file can potentially be modified via the hard
link. So, it was possible, though seemingly very unlikely, for the inode
of the modified object file to be cached.

Command.Fix and Command.Fsck had similar problems, statting the work
tree files after they were in place. Changed them to stat the temp file
that gets moved into place. This does rely on .git/annex being on the
same filesystem. If it's not, the cached inode will not be the same as
the one that the temp file gets moved to. Result will be that git-annex
will later need to do an expensive verification of the content of the
worktree files. Note that the cross-filesystem move of the temp file
already is a larger amount of extra work, so this seems acceptable.

Sponsored-by: Luke Shumaker on Patreon

Added a comment: Fixed in 8.20210715-g3b5a3e168

check if object is modified before starting to send it

Fix bug that caused some transfers to incorrectly fail with "content
changed while it was being sent", when the content was not changed.

While I don't know how to reproduce the problem that several people
reported, it is presumably due to the inode cache somehow being stale.
So check isUnmodified', and if it's not modified, include the file's
current inode cache in the set to accept, when checking for modification
after the transfer.

That seems like the right thing to do for another reason: The failure
says the file changed while it was being sent, but if the object file was
changed before the transfer started, that's wrong. So it needs to check
before allowing the transfer at all if the file is modified.

(Other calls to sameInodeCache or elemInodeCaches, when operating on inode
caches from the database, could also be problimatic if the inode cache is
somehow getting stale. This does not address such problems.)

Sponsored-by: Dartmouth College's Datalad project

comment

fix a place where the inode cache could potentially have gotten stale

When git-annex lock repopulates the object file by copying an associated
file that still has its content, it negected to update the inode cache.

I was not able to actually get this code to successfully repopulate the
object file; the associated file gets replaced with a dangling pointer
before unlock is able to do that. (By what I'm not sure..
reconcileStaged?) Which might be itself a bug, but
anyway this makes me doubtful that this was really leading to a stale
inode cache. Still, in case there is some situation in which it does
work, fixed it to update the inode cache.

comment

more inode cache debugging

propagate debugging into remote's Annex monad

This is needed to make the debugging added in
00733848509940d81026c24919a909acc6dfa21e actually be displayed when
running git-annex get from a local remote.

close this frustrating todo due to lack of followup and/or being fixed

comment

add debugging in sameInodeCache

Added a comment: strace logs

comment

comment

comment

comment

Added a comment: Carification

Added a comment: Reproducible with 8.20210715-g39d747936

comment

Added a comment

Added a comment

comment

sync, merge: Added --allow-unrelated-histories option

Which is the same as the git merge option.

After last commit, this turns out to be needed in the test suite, and when
doing git-annex import from special remote, followed by a git-annex merge.

Sponsored-by: Svenne Krap on Patreon

remove direct mode remnant of merging unrelated histories

sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.

(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)

See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.

This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.

Sponsored-by: Noam Kremen on Patreon

sync --quiet

* sync: When --quiet is used, run git commit, push, and pull without
  their ususual output.
* merge: When --quiet is used, run git merge without its usual output.

This might also make --quiet work better for some other commands
that make commits, like git-annex adjust.

Sponsored-by: Kevin Mueller on Patreon

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

comment

Added a comment: same problem on debian bullseye

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

Added a comment

close

comment

split annexLocations

To avoid mistakes like commit 0ccbed4f6fe0149229533b8448eee7dd6f90dc29,
be explicit about the two variants of this.

Incidentially avoids a small amount of overhead in calling reverse.

Sponsored-by: Shae Erisson on Patreon

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

I understand this now, marking confirmed

Added a comment

Added a comment

Added a comment: appendix

Added a comment: Fixing problem

removed

Added a comment: Fixing problem

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

fix oops

dd31fe7b9e44c42a3e0623cc06cd507bc60930ce broke non-bare repos by using
bare hash dirs first, oops

Added a comment

Clarify

more forumbugs

There are surely a lot more of these..

followup

more forumbugs

fix name

rename tag page

fix syntax

don't treat bugreport tag page as a bug report

forum posts tagged bugreport get moved to the bug list and can be closed

Fix retrieval of content from borg repos accessed over ssh

It was making the borgrepo path absolute.. even when it was a ssh
repository.

Made BorgRepo a newtype, to guard against accidentially treating it like a
FilePath.

Sponsored-by: Graham Spencer on Patreon

comment

fall back to checking lower case hash directories in normal repo

Fix a bug that prevented getting content from a repository that started out
as a bare repository, or had annex.crippledfilesystem set, and was
converted to a non-bare repository.

This unfortunately means that inAnnex check gets slowed down by a stat call
in normal repos when the content is not present. Oh well, such is the cost
of backwards compatability with old mistakes.

Sponsored-by: Mark Reidenbach on Patreon

comment

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

Added a comment

wording

link

better key matching with a regexp

Handles keys that are substrings of other keys, as well as pointer files
that contain a newline after the key.

Note that -S does not match regexp, while -G does by default. Docs are
not clear, determined experimentally. The only other difference in
changing to -G is that if a file used to contain the key and changed
in some way, while still containing the key, -G will match and -S would
not. So eg, annex links that git annex fix rewrites will match, and
files that change lock status will match. Which is an improvement anyway.

Sponsored-by: Jochen Bartl on Patreon

change message to suggest using whereused --historical

have whereused also check the reflog

Since the stash is part of that, it can also find stashed content.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

minor bug in new whereused

whereused --historical

Does not check the reflog, but otherwise works.

It's possible for it to display something that is not an annexed file,
if a non-annexed file somehow ends up containing something that looks
like the key's name. This seems very unlikely to happen, and it would
add a lot of complexity to detect it and somehow skip over that file,
since the git log would need to either be run again, or not limited to 1
result and canceled once enough results have been read.

Also, it kind of seems ok, if a file refers to a key, to consider that
as a place the key was used, for some definition of used. So, I punted
on dealing with that. May revisit later.

Sponsored-by: Brock Spratlen on Patreon

whereused implemented

except --historical

Sponsored-by: Jack Hill on Patreon

add git-annex-filter-branch man page to cabal tarball

forgot to do this earlier

man page for git-annex whereused

And an implementation strategy.

Sponsored-by: Brett Eisenberg on Patreon

link to new catalina build

The old build is still present, but not being updated, so it seems best
to not link to it.

add news item for git-annex 8.20210714

releasing package git-annex version 8.20210714

update for OSX catalina build

comment

Added a comment

close not a bug

comment

comment

followup

comment

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

addistant: honor annex.delayadd for non-large files

assistant: When adding non-large files to git, honor annex.delayadd
configuration.

Also, don't add non-large files to git when they are still
being written to. This came for free, since the changes to non-large
files get queued up with the ones to large files, and run through the lsof
check.

Sponsored-by: Luke Shumaker on Patreon

Added a comment: (partial) filenames in keys

Added a comment

Added a comment

comment

Added a comment