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:
parent
872640549b
commit
b600ad71ce
4 changed files with 40 additions and 9 deletions
|
@ -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
|
||||
)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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.)
|
||||
"""]]
|
Loading…
Reference in a new issue