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)
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
2.30.2
```
+
+> [[applied|done]] --[[Joey]]
--- /dev/null
+[[!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.
+"""]]