Hey, next step could be having the same on Windows? Do you imagine it? File system kernel modules written in C#????
ok, let's stop dreaming... :-P ----- Original Message ----- From: "Jonathan Pryor" <[EMAIL PROTECTED]> To: "Mono List" <[email protected]>; "mono-devel-list" <[EMAIL PROTECTED]> Sent: Monday, September 11, 2006 12:04 PM Subject: [Mono-dev] Announce: Mono.Fuse 0.3.0 > 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 > > > _______________________________________________ > Mono-devel-list mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
