make linkToAnnex freezeContent the object file

v6: Fix annex object file permissions when git-annex add is run on a
modified unlocked file, and in some related cases.

If a hard link is made, don't freeze it; annex.thin
uses writable object files.

Also: For some reason, linkToAnnex used to thawContent src. I can see no
reason why it needed to do that, so I eliminated that.

This commit was sponsored by Brock Spratlen on Patreon.
This commit is contained in:
Joey Hess 2018-09-05 15:27:22 -04:00
parent 872640549b
commit b600ad71ce
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 40 additions and 9 deletions

View file

@ -456,7 +456,7 @@ withTmp key action = do
-
- When a key has associated pointer files, the object is hard
- linked (or copied) to the files, and the object file is left thawed.
-
- In direct mode, moves the object file to the associated file, or files.
-
- What if the key there already has content? This could happen for
@ -564,11 +564,12 @@ data FromTo = From | To
{- Hard links or copies from or to the annex object location.
- Updates inode cache.
-
- Thaws the file that is not the annex object.
- When a hard link was made, this necessarily thaws
- the annex object too. So, adding an object to the annex this
- way can prevent losing the content if the source file
- is deleted, but does not guard against modifications.
- Freezes or thaws the destination appropriately.
-
- When a hard link is made, the annex object necessarily has to be thawed
- too. So, adding an object to the annex with a hard link can prevent
- losing the content if the source file is deleted, but does not
- guard against modifications.
-
- Nothing is done if the destination file already exists.
-}
@ -584,9 +585,12 @@ linkAnnex fromto key src (Just srcic) dest destmode =
return LinkAnnexNoop
Nothing -> ifM (linkOrCopy key src dest destmode)
( do
thawContent $ case fromto of
From -> dest
To -> src
case fromto of
From -> thawContent dest
To -> do
s <- liftIO $ getFileStatus dest
unless (linkCount s > 1) $
freezeContent dest
checksrcunchanged
, failed
)

View file

@ -19,6 +19,8 @@ git-annex (6.20180808) UNRELEASED; urgency=medium
* v6: Update associated files database when git has staged changes
to pointer files.
* v6: Fix some race conditions.
* v6: Fix annex object file permissions when git-annex add is run
on a modified unlocked file, and in some related cases.
* Fix git command queue to be concurrency safe.
* linux standalone: When LOCPATH is already set, use it instead of the
bundled locales. It can be set to an empty string to use the system

View file

@ -31,3 +31,5 @@ Debian Stretch, but building git-annex from source with `stack build`.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, everyday. Thank you for git-annex :-)
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2018-09-05T18:26:33Z"
content="""
Reproduced.
Analysis: In v6, `git annex add` runs `git ls-files --modified`,
which runs the clean filter on the unlocked file as git sees it was
modified. Which in ingests the file with lockingFile = False.
So, the annex object doesn't get the write bit cleared at that point.
Then when `git annex add` gets around to ingesting the file
itself, since the annex object is already present it's used as-is.
`git add` of a new file in v6 also puts content in the annex
with the write bit set. If a different file with that same content is then passed
to `git annex add`, the same thing happens with the symlink to unprotected
content.
So, linkToAnnex should freezeContent. That would solve all cases that lead
to this. (But not when annex.thin has made the annex object a hard link,
in that case it being writable is expected.)
"""]]