From: Joey Hess Date: Tue, 10 May 2022 18:17:29 +0000 (-0400) Subject: thoughts X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~72^2~264 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=b6c781980394556f571fed64b2004edb1228d4ec;p=git-annex.git thoughts --- diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment index 830c27ba00..6fa9576070 100644 --- a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment +++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment @@ -31,8 +31,8 @@ fsck could lock the object file for drop, and then rather than removeing it, move it to a holding location. Then it could move the object file into the right place the same as `get` does. This should avoid the race. Interrupting fsck at the wrong time would leave the object file in this -holding location though. If it used `.git/annex/tmp`, normal commands -like `git-annex get` would recover from an interrupted fsck, though -they would need to do some work to rehash the tmp file. Re-running -fsck would need to also recover from an interrupted fsck. +holding location though. Re-running fsck would need to recover from this +situation. Putting it in `.git/annex/tmp/` might make sense, although +`git-annex get` does not necessarily recover when the object file is +located there. """]]