]> dgit.raspbian.org Git - git-annex.git/commitdiff
avoid redundant freezeContent call
authorJoey Hess <joeyh@joeyh.name>
Wed, 27 Oct 2021 18:11:34 +0000 (14:11 -0400)
committerJoey Hess <joeyh@joeyh.name>
Wed, 27 Oct 2021 18:18:10 +0000 (14:18 -0400)
This opens the potential for the object file to be in place but
git-annex is interrupted before it can freeze it. git-annex fsck already
fixes that situation, which can also occur when lockContentForRemoval
thaws content.

Also improve comment to not be Windows-specific.

Annex/Content.hs
CHANGELOG
doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex.mdwn
doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_3_ab15af768ade06cd4805763391419524._comment [new file with mode: 0644]

index 89c36e612771e6fde7f9c9d91868a695a51ebd80..491d2766cf7a321657d020515b510b3c4a96a1ba 100644 (file)
@@ -342,12 +342,12 @@ moveAnnex key af src = ifM (checkSecureHashes' key)
        storeobject dest = ifM (liftIO $ R.doesPathExist dest)
                ( alreadyhave
                , adjustedBranchRefresh af $ modifyContent dest $ do
-                       freezeContent src
                        liftIO $ moveFile
                                (fromRawFilePath src)
                                (fromRawFilePath dest)
-                       -- On Windows the delete permission must be denied only
-                       -- after the content has been moved in the annex.
+                       -- Freeze the object file now that it is in place.
+                       -- Waiting until now to freeze it allows for freeze
+                       -- hooks that prevent moving the file.
                        freezeContent dest
                        g <- Annex.gitRepo 
                        fs <- map (`fromTopFilePath` g)
index 3858b2edbd25098896c2229a0a7a4225822b65b6..9091a2de3fc9d590fb4a1c1381fc376bb49d9adc 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -22,6 +22,11 @@ git-annex (8.20211012) UNRELEASED; urgency=medium
     when annex.private or remote.name.annex-private is set.
   * Fix using lookupkey and info inside a subdirectory.
     (Reversion in version 8.20211011)
+  * Call annex.freezecontent-command on the annex object file only
+    after it has been moved into place in annex/objects/. This allows
+    the hook to freeze the file in ways that prevent moving it, such as
+    removing the Windows delete permission.
+    Thanks, Reiko Asakura.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 Oct 2021 14:09:13 -0400
 
index 1e8cac42754979def149a23274e7fdf396ee1ac1..8f2c53a57a71aeedc03f2e57612a79a6401d4f22 100644 (file)
@@ -37,3 +37,5 @@ index da65143ab..89c36e612 100644
 2.30.2
 
 ```
+
+> [[applied|done]] --[[Joey]]
diff --git a/doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_3_ab15af768ade06cd4805763391419524._comment b/doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_3_ab15af768ade06cd4805763391419524._comment
new file mode 100644 (file)
index 0000000..66b6655
--- /dev/null
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-10-27T17:56:15Z"
+ content="""
+Ah, making your script smart is reasonable enough.
+
+I hope you might consider sharing the script in a tip?
+
+Looking at your updated patch, you now leave the freezeContent call before it
+moves to the object file, and add another call afterwards. I think that would
+be objectionable if the user has a freeze hook that is expensive
+the run, because it would unncessarily run twice. I fairly well satisfied
+myself in comment #1 that it's ok to defer freezeContent to after it's
+moved the object file into place.
+
+So, I've applied it, but modified to remove that earlier freezeContent.
+"""]]