avoid redundant freezeContent call

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.
This commit is contained in:
Joey Hess 2021-10-27 14:11:34 -04:00
parent 0db7297f00
commit 669037862a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 28 additions and 3 deletions

View 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)

View file

@ -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

View file

@ -37,3 +37,5 @@ index da65143ab..89c36e612 100644
2.30.2
```
> [[applied|done]] --[[Joey]]

View file

@ -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.
"""]]