Feature Request: Propagate File Locks to the Backing Files
guedressel opened this issue · 17 comments
Does gocryptfs do file locking through the fuse layer?
So if a mounted & decrypted file gets a lock by a process using it, will the underlying encrypted source file also have a lock?
No, unfortunately file locking requests are currently thrown away by the go-fuse library. This is mentioned in the go-fuse README as a TODO, so there are good chances of getting it merged.
Ok to close I guess?
Well - actually it's postponed, not closed.
To keep record on the go-fuse progress I created an issue there: hanwen/go-fuse#134
hanwen/go-fuse#134 got closed!
Nice!
Unfortunately, the Flock implementation in go-fuse does not seem to be working yet: hanwen/go-fuse#153 (comment)
Just curious: What is your use case for this? I'm afraid this is going to take a while to land in go-fuse.
This isn't my ticket originally, but my own use case is locking files on a NFS store multiple systems are accessing via gocryptfs.
My use case is to have the underlying encrypted backing files being synced across multiple computers with sync tools (syncany, dropbox, ...).
If an unencrypted file is in use / has a lock it's underlying encrypted file might still be overwritten by such a tool if it can't see the lock.
hanwen/go-fuse#220 seems fixed flock, could you have a look at it? Thanks!
Indeed, I'll take a look in september!
Any news on these? If I understand correctly it prevents gocryptfs to be used with cloud sync tools.
No news here, but this is not related to cloud sync tools.
Dropbox, nextcloud etc work fine
(tbh, i doubt that dropbox etc even look at file locks)
Oh ok, I misunderstood the issue in that case. Thanks for the quick answer.
Out of topic but I don't know where to ask: so will gocryptfs avoid corruption when two cloud sync clients modify the same file on two computers at the same time?
What usually happens is that the cloud sync client creates a file like
my file (copy 1).txt