-
Notifications
You must be signed in to change notification settings - Fork 481
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
[FUSE API] Mutating operations on read-only file system #515
Comments
mhx
changed the title
[FUSE] Mutating operations on read-only file system
[FUSE API] Mutating operations on read-only file system
Jun 30, 2023
FWIW, I can fix the
I'd expect the same thing to happen if |
This is a long standing issue: see #84. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
I'm a bit confused about how WinFsp deals with read-only file systems. With FUSE on Linux, trying to e.g. delete or rename a file, I see:
This makes sense, as indeed both the
unlink
andrename
FUSE operations are unimplemented (i.e.NULL
).On Windows using WinFsp, I see:
So the delete operation fails silently; looking at the source, this seems logical, as
unlink
is skipped whenNULL
. However, it looks like even if it was implemented, the return code of theunlink
operation is ignored by WinFsp.The rename command actually crashes WinFsp, presumably because the function pointer is dereferenced without checking.
I don't quite understand how deleting / renaming (and potentially other operations) work in the native Windows interface, from glancing at the WinFsp code it seems slightly more involved than the rather simply UNIX syscalls.
How to Reproduce
See above.
Behaviors
I'd expect WinFsp's FUSE interface to more closely resemble the behaviour of the Linux implementation; in particular, I'd expect that:
NULL
are handled without crashing; if such operations are triggered, an error should be reported to the userEnvironment
The text was updated successfully, but these errors were encountered: