b2bafdb2fc
That could cause git-annex to get confused about whether a locked file's content was present, when the object file got touched. Unfortunately this means more work sometimes when annex.thin is set, since it has to checksum the file to tell if it's still got the right content. Had to suppress output when inAnnex calls isUnmodified, otherwise "(checksum...)" would be printed in places it ought not to be, eg "git annex get" could turn out not need to get anything, and so only display that. This commit was sponsored by Ole-Morten Duesund on Patreon.
28 lines
968 B
Markdown
28 lines
968 B
Markdown
Touching a locked file in a v6 repository follows the symlink and touches
|
|
the object file. This makes inAnnex's sameInodeCache fail because the keys
|
|
database has a different mtime cached, and so `git annex unlock` doesn't
|
|
populate the file with content, but with a pointer file.
|
|
|
|
Also, `git annex` fsck complains no copies exist even though the symlink is
|
|
pointing at a copy.
|
|
|
|
This seems another reason to not check sameInodeCache for locked content,
|
|
along with
|
|
<http://git-annex.branchable.com/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/>
|
|
--[[Joey]]
|
|
|
|
Note that after initial `git annex add` into a v6 repository, the keys
|
|
database does not have an inode cached. But after an unlock followed by a
|
|
lock, it does. So, here's a complete reproducer:
|
|
|
|
git annex init --version=6
|
|
date > file
|
|
git annex add file
|
|
git annex unlock file
|
|
git annex lock file
|
|
touch file
|
|
git annex unlock file
|
|
cat file
|
|
/annex/objects/...
|
|
|
|
> now [[fixed|done]] --[[Joey]]
|