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

[Valient Gough]

I've been busy for a while, but wanted to follow up eventually.  I
thought I'd seen an 0.2.1 announcement, but this is the latest
announcement I see in my mail archive.

On 9/1/06, Jonathan Pryor <jonpryor at vt.edu> wrote:
> Mono.Fuse is a binding for the FUSE library, permitting user-space
> file systems to be written in C#.

>   I think paths are easier to deal with, and Valient Gough
>       believes inodes are.

Uggg..  I don't think we're communicating very well, because this has
no resemblance to what I said.   What I said is that I find these
low-level APIs less then exciting, and mostly of interest as a
stepping stone for building more interesting APIs.  And it is easier
to build a high-level interface on top of the inode API rather then
the path based API. (1)

But rather then just be annoyed with our inability to communicate,
I've added a simple wrapper to the inode based interface to your code.
 It is available at
http://arg0.net/vgough/download/fuse-lowlevel-0.2.1.tgz

The low-level wrapper is really only tested well enough to run the
included HelloFS example - it hasn't even been used as a base for a
real filesystem.  My thought was to eventually port the high-level
interface (aka the other parts of Sulf project) to use either this or
the SWIG wrappers as the low-level backend.  However this is a
spare-time project since my employers are more interested in that
language which starts with a 'J'.

If you don't want these lowlevel API wrappers in your archive, it
would be great if you split some of the helper functions out of
FileSystem.cs into other files so they can be reused by other classes
(which is why Filesystem.cs is different in my archive then in the
original).

thanks,
Valient

(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.  When you construct a complex filesystem
which handles writes, I suggest letting the following programs write
to it:  rsync, tar, mutt, evolution.  Those will demonstrate lots of
interesting issues having to do with path based APIs (like deleting a
file while it is still open, renaming files while open, renaming on
top of open files, renaming directories while files inside the
directories are open, etc).  Those operations don't change the real
primary key (the inode number), but they change the path in the middle
of accessing files.   It isn't impossible to get right - I like to
think Encfs does a good job, but it isn't trivial and introduces
operation ordering requirements which are otherwise unnecessary.