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 <[EMAIL PROTECTED]> 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. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list