-
Notifications
You must be signed in to change notification settings - Fork 253
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
Issue with idle-unmount and files being used #533
Comments
I think the problem is that the editor copies the file into memory, but does not keep it actually open. At least that's what nano seems to do: Open file
In second terminal check what files nano has open (note: foo.txt is not here)
What editor do you use? Can you check with lsof if it keeps the file open? |
I tried it with a few different editors (nano, xed, emacs, atom). With all of them the directory gets unmounted after the idle-time even though files are in use (open in the editors with unsaved changes made).
then after some (idle-) time:
It seems that lsof (not working for me with 'atom') is just showing the mounted folder but not the actual file being edited; exception being xed which only shows the home directory under which the gocryptfs-folder is mounted. I really hope, I'm not doing some dumb here; can someone reproduce (or not) what I'm seeing? |
Nothing dumb :) I can reproduce the behavior with |
What puzzles me though is that if I open a file (with e.g. nano), I can't unmount the directory manually with The first line of the
|
That is true, however, try this:
|
PS: What I will do is to make the idle unmount behave like
But not that one:
|
I'm seeing a strage (I think) behaviour with the idle-unmount option - if I mount a cipherdir with the idle option on and have a file opened in an editior gocryptfs does unmount the directory. My expectation would be that it would be left mounted as long as files are in use/opened and only unmounts it once all files are closed. Manually unmounting gives an error as expected though.
A sample debug output looks like this:
This is happening with
gocryptfs 1.7.1; go-fuse 0.0~git20190214.58dcd77; 2019-12-26 go1.13.5 linux/amd64
The text was updated successfully, but these errors were encountered: