All data written since mount is lost when system restarted
Issue #100
new
I think due to issues raised in #7 and #98—namely: all writes are saved in RAM until file system is unmounted, and file system can be unmounted before all data will be saved/written—when the system is rebooted in the normal, safe way, it still leads to data written since the archive was mounted to be lost.
Steps to reproduce a problem:
- Mount a ZIP file using fuse-zip
- Write any amount of data to the volume, save your work, close the app, etc. as you would with any other volume
- Reboot/Restart the system normally
Expected result:
Written Data is retained as it is on other volumes.
Actual result:
Written data is lost. When the ZIP file is remounted, the volume is in the same state it was in the last time it was mounted.
Versions:
fuse-zip version: 0.5.0
FUSE library version: 2.9.9
fusermount3 version: 3.14.0
using FUSE kernel interface version 7.19
Logs:
Nothing matching “fuse” or “zip” except the initial mount message like: fuse-zip[PID]: Mounting file system on ARCHIVE.ZIP
Comments (10)
-
repo owner
-
repo owner
- changed status to new
-
reporter
So it’s an issue for upstream FUSE? All other FUSE file systems are subject to the same shutdown sequence and no data is lost. Losing data should never be expected behavior.
-
repo owner
Which FUSE file systems have you tested?
-
reporter
No issues with these fuse mounts: sshfs, cifs (smb), bindfs, or any on the removable usb media I’ve tried so far, too, which had ext2, ext4, and iso9660.
-
repo owner
sshfs, cifs and bindfs doesn’t use caching so can be killed without side effects.
Imagine you’re running vim with unsaved changes in a terminal and invoking reboot command. The editor will be killed during system shutdown and nothing will be saved. So it’s user responsibility to unmount all FUSE file systems before reboot.
-
reporter
Well yeah everyone knows to save data before shutdown. Still, vim creates a swap file and lost data is recoverable, and GUI apps will block the shutdown with a dialog box asking the user to save the data or not first, and also have swap files to recover data. fuse-zip has no recovery data. sshfs, cifs and bindfs are FUSE file systems that do not need unmounting before system shutdown. Even if a fuse-zip was unmounted, #7 would allow the shutdown to proceed before the cached data is fully written. Maybe if it’s possible to turn off caching then catastrophic data loss could be prevented?
-
repo owner
#7 can be solved on kernel side only.
Implementing some sort of recovery in each application contradicts to UNIX principle “make each program do one thing well“.
If you want all write operations to be synced, you can use archivemount. In fuze-zip it’s not too easy to implement sync (I described it in a comment to #98).
-
reporter
Thanks, but I’m not clear on what you mean by sync'ing write operations with archivemount… In its README it says writing is not supported, but then claims it can write but only does it during unmounting, similar to what fuse-zip does, plus other stark warnings that maybe fuse-zip should be warning users about as well, plus no updates for 4 years. Conclusion is there isn’t really any stable way for a userspace compressed filesystem at this time.
-
repo owner
Sorry, I mean AVFS.
- Log in to comment
All FUSE file systems are implemented in the same way: there is a userspace process that handles mountpoint and killing it will terminate all file system contexts.
Operation system shutdown sequence:
If fuse-zip mountpoint wasn’t unmounted before starting shutdown sequence, the filesystem process will be terminated on step 2 and you’ll lost all unsaved data. So it’s the expected behavior.
All that I can do is to handle TERM signal to initiate file system unmount. But unmounting can take time so the process may be killed by the OS before unmount finish.