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

reopen on second thought

Browse source
This commit is contained in:
Joey Hess 2023-06-22 13:48:48 -04:00
parent 6c84aabe63
commit 19570263c0
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 21 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -9,6 +9,3 @@ Also, with `annex.thin`, the [[invariant|internals]] that `.git/annex/objects/aa
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]] [[!tag confirmed]]
> documentation updated to mention this unfixable wart. Ugh. [[done]]
> --[[Joey]]

3
doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment
View file

@ -24,6 +24,5 @@ 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 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. 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 I've made the docs warn about it better.
can be done. The only real fix would be to remove annex.thin.
"""]] """]]

20
doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2023-06-22T17:45:08Z"
content="""
Ugh, I had closed this as not solvable, but on second thought, it's a very
real wart and if it's not solvable that doesn't make it not a problem.
And it does seem that it could be solved in some outside the box way.
For example, what if thin files were not hard links to the object file?
Now, they *have* to hard link to somewhere, to prevent git checkout from
deleting the only copy of a thin file. But it could hard link to a
different name in the object directory. One that symlinks do not point to.
Then `git-annex fix` or fsck would need to notice when a symlink points to
an object file that is missing, and copy the thin file to it to populate
it. And, something might also want to reap object files that have become
only used by thin files.
"""]]