From b6c781980394556f571fed64b2004edb1228d4ec Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 10 May 2022 14:17:29 -0400 Subject: [PATCH] thoughts --- .../comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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. """]] -- 2.30.2