[Mono-dev] [Mono-list] Announce: Mono.Fuse 0.2.0 (+ Required mcs & mono patches)

[Jonathan Pryor]

On Sun, 2006-09-10 at 21:07 -0700, Valient Gough wrote:
> (1) The reason it is harder to use the path-based API for a complex
> filesystem has nothing to do with lines of code.  The problem is due
> to the data model, what I tried to explain before - with the path
> based API, libfuse is remapping the primary key (the kernel supplied
> inode numbers) to a mutable / non-unique key (a path) and then using
> that as the primary key.

I think this is why they changed `struct fuse_operations' to deprecate
the getdir() method and replaced it with a readdir() method which
provides a `struct stat' to the filler function pointer.  This change
requires FUSE 2.3, and setting the FUSE_USE_VERSION macro in order to
use it.  I see that neither Sulf nor fusewrapper set this macro.

>From what I can gather from email archives, they added the readdir()
replacement precisely because of apps like Mutt, so that the filesystem
programs could provide an inode for stability tracking purposes.

The current Mono.Fuse.FileSystem.OnReadDirectory() method now allows
providing this `struct stat' information, so hopefully things should
work sanely (though I have yet to actually test it, and coming up with
an a good test case which exercises reading, writing, and renaming
concurrently is difficult).  Furthermore, given that reading & writing
currently take an OpenedPathInfo which can (optionally) store a file
handle (file descriptor), I don't see how reading & writing would be
impacted by file renames (see example/RedirectFS/RedirectFS-FH.cs).

Also, a file can't be deleted while it's still open if the *Handle
methods use file descriptors, as even after OnRemoveFile() is called the
file handle would still be valid, and won't be invalided until
OnReleaseHandle() is called.  The same should be true for directories,
if a directory handle is used (again, see
example/RedirectFS/RedirectFS-FH.cs).

 - Jon