Please describe the problem.
With a v6 repo, if I unlock an annex file, change it, and then add it back, the annex object is writeable.
What steps will reproduce the problem?
git init tmp-v6 && cd tmp-v6
git annex init --version=6
echo foo >foo && git annex add foo && git commit -m'add foo'
git annex unlock foo
echo more >>foo && git annex add foo && git commit -m'modify foo'
ls -l $(readlink foo)
# -rw-r--r-- 1 kyle kyle 9 Aug 29 17:18 .git/annex/objects/60/QW/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d/SHA256E-s9--323409d9a706bc08d0b2c7f71309e21a757367c81cffb405a88e61749d79952d
What version of git-annex are you using? On what operating system?
git annex version
# git-annex version: 6.20180808-gdad627fa9
# build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser Feeds Testsuite
# dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
# key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
# remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
# operating system: linux x86_64
# supported repository versions: 3 5 6
# upgrade supported from repository versions: 0 1 2 3 4 5
# local repository version: 6
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 
Hmm, I don't reproduce this here.
Also AFAIK there is no difference in the code path used here to move a file into the annex between v5 and v6. Does it happen with v5?
Seems there is either something in your environment (umask, core.sharedRepository git config etc though I don't think any of those would explain this particular file mode) or the build on stretch is somehow behaving differently.
just wanted to say that I see the same (thanks Kyle for copy/pasteable example):
tried with umask 022 - the same
tried across a number of boxes, and other users, and older git-annex -- the same effect everywhere. The common denominator - I was using neurodebian build (will check next)
No, it doesn't:
Reproduced.
Analysis: In v6,
git annex addrunsgit 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 whengit annex addgets around to ingesting the file itself, since the annex object is already present it's used as-is.git addof 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 togit 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.)