releasing package git-annex version 8.20210803

whitespace

Added a comment

Added a comment: don't give up ;)

Added a comment

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

fix test suite

14683da9ebd629c3f77405b646d3f5661874f9d6 caused a test suite failure.
When the content of a key is not present, a LinkAnnexFailed is returned,
but replaceFile then tried to move the file into place, and since it was
not written, that crashed.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

fix missing new lines in processTranscript

initial observation of .dot filename to consider having .dot extension

Added a comment: Also seeing this behaviour

Added a comment

work around strange auto-init bug

git-annex get when run as the first git-annex command in a new repo did not
populate unlocked files. (Reversion in version 8.20210621)

I am not entirely happy with this, because I don't understand how
428c91606b434512d1986622e751c795edf4df44 caused the problem in the first
place, and I don't fully understand how skipping calling scanAnnexedFiles
during autoinit avoids the problem.

Kept the explicit call to scanAnnexedFiles during git-annex init,
so that when reconcileStaged is expensive, it can be made to run then,
rather than at some later point when the information is needed.

Sponsored-by: Brock Spratlen on Patreon

remove unused code

remove second pass in scanAnnexedFiles

The pass was needed to populate files when annex.thin was set,
but in commit 73e0cbbb19703f08daf783d8788370726f852162,
reconcileStaged started to do that. So, this second pass is not needed
any longer.

bug

close

I'm now reasonably sure I've identified both cases where this can
happen. v8 upgrades and certian filesystems eg NFS. Both are handled as
well as can be, though it may involve some extra checksumming work.

Fix a rounding bug in display of data sizes

Eg, showImprecise 1 1.99 returned "1.1" rather than "2". The 9 rounded
upward to 10, and that was wrongly used as the decimal, rather than
carrying the 1.

Sponsored-by: Jack Hill on Patreon

bugreport: git-annex info .   formats  2 TB as 1.1 TB

fsck: Detect and correct stale or missing inode caches for object files

An easy way to see this in action is to have an unlocked file, and touch the
object file.

While all code that compares inode caches for object files needs to be
prepared for this kind of problem and fall back to verification, having
fsck notice it and correct it is cheap (as long as fsck is being run
anyway) and ensures that if it happens for some unusual reason, there's a
way for the user to notice that it's happening.

Not that, when annex.thin is in use, the earlier call to isUnmodified
(and also potentially earlier calls to inAnnex in eg, verifyLocationLog)
will fix up the same problem silently. That might prevent the warning
being displayed, although probably it still will be, because the
Database.Keys write of the InodeCache will be queued but will not have
happened yet. I can't see a way to improve this, but it's not great.

Sponsored-by: Dartmouth College's Datalad project

split verifyKeyContent

This avoids it calling enteringStage VerifyStage when it's used in
places that only fall back to verification rarely, and which might be
called while in TransferStage and be going to perform a transfer after
the verification.

comment

improve comment wording

add note

remove unused parameter

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

simplify code

remove unncessary debugs

Keeping the ones in Annex.InodeSentinal

Added a comment: Cause cannot (only) be a v7->v8 upgrade

use SQL.addInodeCaches

This avoids deadlock when opening the database handle calls
reconcileStaged.

fix problem populating pointer files

This is a result of an audit of every use of getInodeCaches,
to find places that misbehave when the annex object is not in the inode
cache, despite pointer files for the same key being in the inode cache.

Unfortunately, that is the case for objects that were in v7 repos that
upgraded to v8. Added a note about this gotcha to getInodeCaches.

Database.Keys.reconcileStaged, then annex.thin is set, would fail to
populate pointer files in this situation. Changed it to check if the
annex object is unmodified the same way inAnnex does, falling back to a
checksum if the inode cache is not recorded.

Sponsored-by: Dartmouth College's Datalad project

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