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

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