Would it be possible to make thin work in locked mode? In other words, could locked mode use hardlinks instead of symlinks then thin is set?
Such a combined mode would have all the benefits of locked mode (protection, easy-to-spot missing files) and of direct mode (no duplication of files). It would also (partially) solve the problems discussed in day 601 v7 default and ?symlinks for not-present unlocked files.
Here is an example of how this could work from the user prospective:
$ mkdir foobar && cd foobar/ && git init . && git annex init foobar
$ echo "aaaa" > a && echo "bbbb" > b
$ git config annex.thin true
$ git annex add a b
[...] ok
$ git annex sync
[...] ok
$ ls
a b # note: no symlinks
$ echo "foo" > a
bash: a: Permission denied
$ git annex drop --force a
$ ls
a@ b # note: symlink for missing file
It would have to be represented to git the same as unlocked files are (as annex pointer files) because representing as symlinks would cause eg
git addto do the wrong thing.So the git tree would be the same as
git annex adjust --unlocksets up. The only difference then seems like it would be the mode of the files, which would all have their write bits removed.Unofortunately, that means no easy spotting of removed files via broken symlinks.
And it seems all the files in the tree would need to be locked in this way, because there's no way to differentiate at the git level between an unlocked file and a file locked in this way (since git does not track write bits).
If ?symlinks for not-present unlocked files got implemented, it could work though. Ie, have a
git annex adjustmode that represents present files as unlocked, but with the write bits unset, and that represents missing files as symlinks. Added a note to that todo about the idea.Well, it does have the benefits of locked mode, but does it really gain back any benefits of direct mode?
Direct mode didn't duplicate files. But locked mode with annex.thin doesn't duplicate files either, except for on a filesystem that doesn't support hard links. But this new mode relies on hard links too.
Direct mode allowed modifying files in place. But locked mode does too, more safely than direct mode (except when using annex.thin, then it's the same).
Direct mode represented missing content as dangling symlinks (on filesystems that support them). And this seems to be the only benefit of direct mode that this new mode would gain back.
If the benefit of this new mode is only that, all that's really needed is for the missing files to be represented as symlinks. Earlier I said:
I now see that unsetting the write bit is not necessary to get the only benefit of this new mode. Instead, the unlocked files can work just like usual, being a copy of the content. And if the user doesn't want to store two copies, they can enable annex.thin to get hardlinks, allowing in-place modification.
If it actually made sense to unset the write bit of unlocked files, it could be a config independant from this new mode. But I don't currently see any real benefit to doing that. As far as I can see, this new mode + unset write bit does not have any advantages at all compared with regular locked files.
I've implemented
git annex adjust --unlock-presentthat unlocks files whose content is present, while keeping the non-present files locked, so dangling symlinks.It doesn't mess with the file permissions, but otherwise that's what was requested here.