Re:FUSE for Windows (Score 1)

During the course of development of SftpDrive [www.sftpdrive.com], we learned how much harder it is to develop a NT based filesystem than a simple VFS. One of the biggest problems with Windows filesystem development is the sheer lack of good examples that explain what is going on. With VFS you have a well defined architecture that "makes sense." With a windows filesystem you have a variety of messages you respond to, that send you huge parameter blocks that ultimately decide what type of operation will be performed. None of the high level architecture is in any way documented, and up until recently the IFS kit costed a developer $1200 and only consisted of a HUGE header file, along with source to SMB, CDFS, and FAT. These sources are well documented, but do nothing to explain why a particular thing is set up the way it is. Look around for some open source windows filesystems... there are basically none, and certainly none that people are running. We took the road of implementing a a FUSE like interface for windows, with a full custom driver that communicates with a very nice service. One approach people sometimes take is to write a SMB loopback server in userland, and then use that as their filesystem driver. It's kind of a nightmare. Try the openafs client out sometime -- you won't go a day without it locking explorer or tanking some application. Kernel programming for windows is a nightmare. Looking through all the material at osronline.com is extremely helpful, those guys are geniuses. When it comes down to it, something like a filesystem really needs to be tooled and polished and have all the edge cases weeded out over time. It's particularly difficult because a filesystem can connect up with any application in the system and given what a wide variety of installations people have, replicating specific conditions is often near impossible. Black Magic Debugging. Enjoy writing FUSE for windows :) again-- http://www.sftpdrive.com/