Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Propagate File Locks to the Backing Files #39

Open
guedressel opened this issue Sep 27, 2016 · 17 comments
Open

Feature Request: Propagate File Locks to the Backing Files #39

guedressel opened this issue Sep 27, 2016 · 17 comments

Comments

@guedressel
Copy link

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?

@rfjakob
Copy link
Owner

rfjakob commented Sep 28, 2016

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.

@rfjakob
Copy link
Owner

rfjakob commented Oct 5, 2016

Ok to close I guess?

@guedressel
Copy link
Author

Well - actually it's postponed, not closed.
To keep record on the go-fuse progress I created an issue there: hanwen/go-fuse#134

@rfjakob rfjakob reopened this Oct 6, 2016
@rfjakob rfjakob changed the title File locking Feature Request: Propagate File Locks to the Backing Files Oct 18, 2016
@guedressel
Copy link
Author

hanwen/go-fuse#134 got closed!

@rfjakob
Copy link
Owner

rfjakob commented Apr 29, 2017

Nice!

@rfjakob
Copy link
Owner

rfjakob commented May 2, 2017

Unfortunately, the Flock implementation in go-fuse does not seem to be working yet: hanwen/go-fuse#153 (comment)

@rfjakob
Copy link
Owner

rfjakob commented May 5, 2017

Just curious: What is your use case for this? I'm afraid this is going to take a while to land in go-fuse.

@charles-dyfis-net
Copy link
Contributor

This isn't my ticket originally, but my own use case is locking files on a NFS store multiple systems are accessing via gocryptfs.

@guedressel
Copy link
Author

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.

@invis-z
Copy link
Contributor

invis-z commented Sep 2, 2018

hanwen/go-fuse#220 seems fixed flock, could you have a look at it? Thanks!

@rfjakob
Copy link
Owner

rfjakob commented Sep 2, 2018

Indeed, I'll take a look in september!

@kototama
Copy link

kototama commented Apr 4, 2019

Any news on these? If I understand correctly it prevents gocryptfs to be used with cloud sync tools.

@rfjakob
Copy link
Owner

rfjakob commented Apr 4, 2019

No news here, but this is not related to cloud sync tools.

Dropbox, nextcloud etc work fine

@rfjakob
Copy link
Owner

rfjakob commented Apr 4, 2019

(tbh, i doubt that dropbox etc even look at file locks)

@kototama
Copy link

kototama commented Apr 4, 2019

Oh ok, I misunderstood the issue in that case. Thanks for the quick answer.

@kototama
Copy link

kototama commented Apr 4, 2019

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?

@rfjakob
Copy link
Owner

rfjakob commented Apr 4, 2019

What usually happens is that the cloud sync client creates a file like

my file (copy 1).txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants