mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

document annex.thin risk to locked files pointing at same content

Browse source
This commit is contained in:
Joey Hess 2023-06-21 15:39:15 -04:00
parent 928b2a4839
commit 6c84aabe63
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 38 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn
View file

@ -7,3 +7,8 @@ Also, with `annex.thin`, the [[invariant|internals]] that `.git/annex/objects/aa
[[`git-annex-drop`|git-annex-drop]] succeeds but does not actually drop the file. [[`git-annex-drop`|git-annex-drop]] succeeds but does not actually drop the file.
Also, even if the current repo is trusted, with `annex.thin`, an unlocked file should not count as a trusted copy. Also, even if the current repo is trusted, with `annex.thin`, an unlocked file should not count as a trusted copy.
[[!tag confirmed]]
> documentation updated to mention this unfixable wart. Ugh. [[done]]
> --[[Joey]]

29
doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment Normal file
View file

@ -0,0 +1,29 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2023-06-21T19:28:52Z"
content="""
Confirmed this is still a problem. `git-annex fsck` does detect and deal
with it, by eg deleting the corrupted object.
It seems like it would be hard for git-annex to make other files that use
the same object be unlocked. Consider a repo with one file, that is
unlocked and uses an object. Then a `git merge` adds another, locked file,
using the same object. git-annex didn't have a chance to run at all, and
now the stage is set for this problem to happen if the user appends to the
unlocked file.
In a way, the docs for annex.thin do warn the user about this. If you squint
just right:
... but when a modification is made to a
file, you will lose the local (and possibly only) copy of the
old version
But, git-annex goes out of its way to avoid 2 unlocked files being hardlinked
when using annex.thin. So it seems wrong that a locked file and an unlocked file
will be hard linked, and that the locked file can get corrupted.
Ok, I've made the docs warn about it, and I think that is just the best that
can be done. The only real fix would be to remove annex.thin.
"""]]

5
doc/git-annex.mdwn
View file

@ -1156,7 +1156,10 @@ repository, using [[git-annex-config]]. See its man page for a list.)
Set this to `true` to make unlocked files be a hard link to their content Set this to `true` to make unlocked files be a hard link to their content
in the annex, rather than a second copy. This can save considerable in the annex, rather than a second copy. This can save considerable
disk space, but when a modification is made to a file, you will lose the disk space, but when a modification is made to a file, you will lose the
local (and possibly only) copy of the old version. So, enable with care. local (and possibly only) copy of the old version. Any other, locked
files in the repository that pointed to that content will get broken
as well (`git-annex fsck` will detect and clean up after that).
So, enable this with care.
After setting (or unsetting) this, you should run `git annex fix` to After setting (or unsetting) this, you should run `git annex fix` to
fix up the annexed files in the work tree to be hard links (or copies). fix up the annexed files in the work tree to be hard links (or copies).