I'd love to use git annex for my document archive, but my use case necessitates the archive to be stored encrypted while at rest. It also needs to be easily stored on a number of cloud storage providers.
I usually use Cryptomator and gocryptfs - amongst others - to do this.
I'd like to use git annex within one of those vaults, but it seems they are not compatible. With gocryptfs it shows me that the files changed while being added if I try to do a git annex add . on the folder.
Is this an issue caused by some fundamental architectural incompatibility between git annex and these kinds of encryption tools or is there something I can do?
-kooption for additional mount options. Maybe try things likenoatimeand the like? Or other options to gocryptfs? I had to massage a Samba mount quote a bit to be workable with git annex.I wonder if gocryptfs does not have stable inode numbers?
The "changed while it was being added" message happens if git-annex saw one inode number when it started adding the file, and a different one at the end.
Changes to the mtime, device id, or file size will result in the same message.
You might try running the
statcommand on a file before and after and see what changed.Sorry, didn't see you guys answered.
I've tried the "noatime" mount option, but no change.
I think joey might be on to something. As far as I understand this github issue, there could be something to this.
I guess the only remaining solution would be something like Veracrypt. What a pity.
Thank you for your help.
After successfully using git-annex + gocryptfs for several years now, I came across this issue because I also am no longer able to add files ("... changed while it was being added") after upgrading from bullseye to bookworm.
The issue appears with gocryptfs 2.3.1+b3, but if I downgrade to gocryptfs 1.8.0-1+b6 it works again.
It doesn't seem to be an inode number issue, but I do see the atime and ctime of the file change before and after running
git annex add:The filesystem was mounted as
/home/dave/.encrypted/Finances on /home/dave/Finances type fuse.gocryptfs (rw,nosuid,nodev,noatime,user_id=1000,group_id=1000,max_read=131072).This is with git-annex 10.20230126-2.
I am happy to debug further if someone wants to point me in a useful direction.
Some additional experiments:
From the above, I can see that
-ko noatimedoesn't do anything, but the ctime change is something unique to git-annex, not just from opening and reading file contents. (I've used git-annex on filesystems without noatime before, so I didn't think noatime support was mandatory?)But wait... why is the file 0444?
OK, so setting it back to 0644 modifies ctime.
And running
git annex addchanges it back to 0444, and updates ctime. So that's why that change is being observed.So I don't think gocryptfs is doing anything unexpected w.r.t. modifying the file out from under git-annex. Is there a way to get more detailed information about what git-annex thinks has changed?
This is a filesystem bug. I reported it here: https://github.com/rfjakob/gocryptfs/issues/724
git-annex addmakes a hard link to the file and then stats the hard link before and after hashing. Due to this filesystem bug, it gets a different size.One workaround is:
Although setting annex.crippledfilesystem has other effects, including git-annex not locking down permissions of annexed files. So I don't know if I'd really recommend that workaround.
It would be possible for git-annex to work around this by statting the file before making the hard link, rather than statting the hardlink after creation. But I don't think I want to work around filesystem breakage like that.
annex.crippledfilesystemoption. I agree the latter sounds sub-optimal but I'll keep it in mind if staying on the 1.8 release becomes untenable before the Gocryptfs bug is fixed. I'll follow the linked Github issue for updates on that.