[FUSE API] Mutating operations on read-only file system

[mhx]

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:

mhx@sauron mnt $ rm -f INSTALL 
rm: cannot remove 'INSTALL': Function not implemented
mhx@sauron mnt $ mv INSTALL INSTALL.x
mv: cannot move 'INSTALL' to 'INSTALL.x': Function not implemented

This makes sense, as indeed both the unlink and rename FUSE operations are unimplemented (i.e. NULL).

On Windows using WinFsp, I see:

C:\Users\mhx\git\dwarfs\build-vcpkg\boost>del INSTALL

C:\Users\mhx\git\dwarfs\build-vcpkg\boost>rename INSTALL INSTALL.xxx
The I/O operation has been aborted because of either a thread exit or an application request.

So the delete operation fails silently; looking at the source, this seems logical, as unlink is skipped when NULL. However, it looks like even if it was implemented, the return code of the unlink 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:

• all cases where operations are NULL are handled without crashing; if such operations are triggered, an error should be reported to the user
• return values from operations are handled and errors are somehow reported to the user

Environment

• OS version and build: 10.0.22621
• WinFsp version and build: 2.0.23075

[mhx]

FWIW, I can fix the rename crash by implementing the operation and making it return -ENOSYS (or -EROFS):

C:\Users\mhx\git\dwarfs\build-vcpkg\boost>rename INSTALL INSTALL.xxx
Incorrect function.

I'd expect the same thing to happen if rename is NULL in fuse_operations.
I'd expect something similar to happen for unlink.

[billziss-gh]

This is a long standing issue: see #84.