bugs/Delete data/update location log when a special remote fails to fsckgit-annexhttp://git-annex.branchable.com/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/git-annexikiwiki2017-06-26T17:41:18Zcomment 1http://git-annex.branchable.com/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b/joey2017-06-26T17:41:18Z2017-06-26T17:14:56Z
<p><code>fsck --from remote</code> is supposed to update the location log when it
determines that the remote does not contain the file.</p>
<p>But in your case, the decryption failure appears to fsck as a transfer
failure, which as you note can be transient. So it doesn't update the
location log.</p>
<p>It seems that what's needed is different errors to be returned when
download fails, vs when download succeeds but decryption/verification fails.
Then fsck could mark the file as not being present in the remote
in the latter case.</p>
<p>Although, that would leave the presumably corrupted encrypted data in the
remote. (Unless fsck also tried to delete it.)</p>
<p>Also, decryption can fail for other reasons, eg missing gpg keys,
and in such a case, it would be bad for fsck to decide that the remote
didn't contain any content! (And super bad for it to delete it from the
remote!!)</p>
<p>So hmm, I'm not sure about that idea.</p>
<p>Your idea of getting a list of files that fsck failed to download
is certianly useful. Perhaps a good way would be to make <code>git annex fsck
--from remote --json</code> work, then the json output could be parsed to get a list of
files, and you could use <code>git annex drop --from remote</code> to remove the bad
data. That was the easiest possible thing, so I've made that change.</p>