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

followup and close as this is intentional

Browse source
This commit is contained in:
Joey Hess 2020-06-30 10:41:26 -04:00
parent e2cddc28a5
commit 7a4253a155
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 23 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/Running_fsck_on_a_remote_drops_bad_files.mdwn
View file

@ -35,3 +35,5 @@ git-annex: fsck: 1 failed
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes it stores most of my data
> [[notabug|done]] --[[Joey]]

21
doc/bugs/Running_fsck_on_a_remote_drops_bad_files/comment_1_c75030329f9769e557aba68193ce1801._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2020-06-30T14:33:08Z"
content="""
The corrupted file is downloaded from the remote, and that copy of the file
gets moved to .git/annex/bad/ when fsck determines it's corrupt. A message
is displayed giving the path where the content is left.
The only time that's not done is if the local repository has its own copy
of the file. In that case, there's not much benefit to accumulating bad
copies in .git/annex/bad since there's still a (presumably) good copy.
If fsck left corrupted content on the remote, that would risk actual data
loss. Consider if a second repository also had access to the remote, and
in that repository you ran git-annex drop. It would see that the remote
still contains the file, so assume the content is good, and so go ahead and
drop the content from the second repository. That might be the only
uncorrupted copy of the file it's lost. So once we know that the content is
corrupt, the safe thing to do is move it out of the way.
"""]]