Hi all,
I’m currently a grad student taking an OS class at U Wisconsin, and I was fishing around for a project. One of the ideas I came up with was to create a Windows port of FUSE. (If you’re not familiar with it, I’ll provide a summary at the end of this message.) On its face it didn’t seem like it would be a rather possible project, but after doing some reading it seems that lot of places put time estimates for writing a Windows file system on the order of years. So this is pretty discouraging.
But otherwise I think it would be a pretty interesting and extremely useful project. (Ironically, it seems the harder it would be to implement FUSE the more useful it would be…) So before I give up on the idea, I thought I’d ask here if there’s any way that it’s possible. It wouldn’t have to be production quality or anything, though it would have to work somewhat reasonably well. So on a scale of 1 (“this is totally possible”) to (“you’d be more likely to create peace in the Middle East”), how crazy of an idea is this?
This would be about a two month project with two or three people. I haven’t done any file system work in the past, but I have done a non-trivial amount of Linux programming. (So I’m used to API targets that move from point-release to point-release and aren’t documented pretty much at all besides the code.) We also have the FUSE source we could use at least as a high-level guide of what they do (and I would think I might be able to get permission to actually incorporate the source into our project if it would help), so it’s not like we’d be working completely blind.
I’m also not an expert in Windows architecture or driver development, so if there’s a way to do this you think I might not see that would be nice to know as well. There are really only two restrictions other than the time we have to put in, which are that (1) I don’t want this to be just a shell namespace extension and (2) I would *really* like there to be source-compatibility with existing FUSE filesystems, possibly with the aid of Services for Unix. (There doesn’t I think need to be compatibility with the kernelspace-userspace API of FUSE; in other words, we could modify the library (that we definitely can do without license issues), perhaps with somewhat of a compatibility layer to smooth out differences such as filename matching. There just needs to be a way to build such a translation layer.)
Thanks,
Evan Driscoll
Appendix: Summary of FUSE
FUSE stands for Filesystems in UserSpaceE. It was originally written for Linux, and has since been ported to FreeBSD and OS X. FUSE has two parts, a kernel module and a userspace library, and filesystems built upon it are essentially daemon processes (services if you prefer) that link to the FUSE library to form the userspace part of a FUSE filesystem. (I’ll call the US part a server in keeping with microkernel terms.)
When a filesystem is mounted with fusermount, it starts the server. The server reads /dev/fuse, and blocks. When an application submits a I/O request to this filesystem, the request first goes to the FUSE kernel module. The kernel module does some multiplexing, and responds to the read of /dev/fuse with the request information, waking up the appropriate server. The server can then go and satisfy the request in whatever way it needs to, at which point it writes back to /dev/fuse, waking the kernel thread responding to the original application request which can then go and return the result to the application.
(At least I think this is how it works.)
There are a large number of filesystems built on FUSE, of which two interesting ones are wayback, a versioning filesystem, and sshfs, which lets you mount remote directories while it behind the scenes issues appropriate sftp commands.