[Mono-dev] Announce: Mono.Fuse 0.3.0

[Jonathan Pryor]

Mono.Fuse is a C# binding for the FUSE library.

This release features a near complete change in the public FileSystem
API; a complete API change list is available at:

http://www.jprl.com/Blog/archive/development/mono/2006/Sep-11.html

Hopefully this will be the last major API change, though I would
appreciate any and all feedback on the current API.

The most "interesting" change is for OnReadDirectory().  It was
previously:

	protected virtual Errno
		OnReadDirectory(string path, out string[] paths, 
		OpenedFileInfo info);

It is now:

	protected virtual Errno
		OnReadDirectory(string path, OpenedPathInfo info, 
		out IEnumerable<FileSystemEntry> paths);

That is, `out string[]' is now `out IEnumerable<FileSystemEntry>'.  This
allows for two things:

1.  A performance boost: an array containing the names of all file
system entries in `path' doesn't need to be created all at once.  For
large directories (hundreds-thousands of files), this can really slow
things down.  The IEnumerable interface allows file system entries to be
retrieved piecemeal.

2.  C# iterators can be used to implement directory reading.  From
HelloFS.cs:

	private IEnumerable<FileSystemEntry> GetEntries ()
	{
	    yield return ".";
	    yield return "..";
	    yield return "hello";
	    yield return "data";
	    if (have_data_im)
	        yield return "data.im";
	}

	protected override Errno OnReadDirectory (string path,
	        OpenedPathInfo info, 
                out IEnumerable<FileSystemEntry> paths)
	{
	    paths = GetEntries ();
	    return 0;
	}

I think (2) is particularly cool.


Design Questions: 

OnReadDirectory() uses FileSystemEntry, which is:

	class FileSystemEntry 
	    public string Path {get;}
	    public Stat Stat;
	    public FileSystemEntry (string path);
	    public static implicit operator FileSystemEntry (string);
	}

This has a public field Stat, which is against normal design guidelines.
This was done because Stat is a 96-byte structure, so these shouldn't be
created on the stack that often, and a read/write Property would require
much more stack use.  Is this reasonable?

The Stat field is optional.  It is only used Stat.st_ino is non-zero (as
FUSE 2.5.3 currently only reads the st_ino & st_mode fields, though I
imagine this could be extended in the future).  Is this reasonable?  Or
should an alternative mechanism be used to determine when the Stat
instance should be used?

Is it a good idea to have the implicit conversion from string to
FileSystemEntry?


Download:

Mono.Fuse 0.3.0 is available for download at:

http://www.jprl.com/Projects/mono-fuse/mono-fuse-0.3.0.tar.gz

Thanks,
 - Jon