forum/Making a git-annexy symlink "known"?git-annexhttp://git-annex.branchable.com/forum/Making_a_git-annexy_symlink___34__known__34____63__/git-annexikiwiki2016-05-10T17:44:38Zcomment 1http://git-annex.branchable.com/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce/joey2016-05-10T17:20:58Z2016-05-10T17:04:20Z
<p>fsck sees that the (lack of) location
log accurately states that the content is not present, and so avoids
writing to the log.</p>
<p>If fsck always wrote to the log when content was not present, running
fsck in sparse repos would bloat the location logs unncessarily.</p>
<p>But I suppose that it makes sense for fsck to notice that the key
was not known and write to the log in this particular case.
I've gone ahead and made that change.</p>
<p>It's not clear to me though, why this workflow of copying over symlinks,
and adding them and reinjecting is better than just moving over content and
adding it.</p>
comment 2http://git-annex.branchable.com/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_2_de77cc2bee45706c4bbe407d8846778e/CandyAngel2016-05-10T17:44:38Z2016-05-10T17:44:38Z
<p>It protects against adding in corrupted files without noticing.</p>
<p>If I move the symlink as a real file, the receiving git-annex will rehash it and, if it is corrupted, effectively change the symlink to a corrupt file with no way to tell this has occured.</p>
<p>This method leaves the transplanted symlink broken (and may be fixed by a reinject of a good copy of the file from another drive) and the corrupt content would be left behind by the reinject. This makes it very obvious something has happened.</p>
<p>Thank you for making these changes to support my use case. I really hope it doesn't break anyone else's!</p>