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

[Valient Gough]

On 9/11/06, Jonathan Pryor <jonpryor at vt.edu> wrote:
> On Sun, 2006-09-10 at 21:07 -0700, Valient Gough wrote:
> 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.

The getdir() / readdir() changes don't affect my wrappers - those are
for the path based API.

> >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.

Yes, but this is only vaguely related.  You might have noticed that I
reported that problem, and I think even provided some of the changes
to help with this case.  One of the tricks Mutt does is create hard
links and then check that the inode numbers were identical as a
race-condition check.  That solves one particular problem with Mutt
running under a virtual FS.

That's the interesting thing with running random programs under a
filesystem - you find out that behavior which programs expect isn't
necessarily guaranteed by the filesystem documentation.

> 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).

There is a program "fsx-linux" which you might find useful.  I've
found bugs in FUSE itself with this program in the past while trying
to debug my own filesystems.

> 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).

I wrote a fair amount of the rename and delete handling code in
libfuse, which has been there since version 1.9, so I feel confident
in describing how it works.  You're right that a file handle will
still be valid, but the path name will have changed.  The NFS trick is
used for the path-based API (unnecessary with the inode api) - a
delete is turned into a synchronized rename with the final delete
postponed until files are closed.

Did you try rsync and Evolution?  They really do create lots of
rename-while-open events that are useful for testing assumptions
related to the primary key (path in your case).

Now consider edge cases related to this NFS trick.  Consider that you
have an open file and the file is removed.  Now the directory is
supposed to be empty (although because of the NFS trick it isn't) and
the directory is removed.  Does it succeed, or does it fail, and does
it match what a program might expect from a 'normal' filesystem?  No
point arguing about what we expect to happen - rsync can cause such a
condition, or it could be constructed by hand, so it is easy to test.

Sounds like minor issues, and they are mostly.  Only a few programs
will probably be affected, and most of them in a way that doesn't
cause an serious problem (meaning data loss).  If the broken programs
are used by few people, it may takes years to hear about it.  But if
it causes Evolution to corrupt its db files, the feedback may not be
so friendly.

regards,
Valient

PS.  You know about the language wrapper FUSE wiki page?
(http://fuse.sourceforge.net/wiki/index.php/LanguageBindings).  Might
want to list your wrapper so that people outside mono-devel can find
it.