rdos wrote:
The idea to use FUSE to get access to a lot of filesystems without much effort, particularly ext and NTFS is compelling, I wonder how well this would work in practice.
I wouldn't say "without much effort", because you'll have to port a linux kernel driver to your OS. But yes, you do that once and you get access to many many file systems. I wrote about it
on the wiki, but that page is more focused on how to implement a FUSE driver instead of how to port it. In a nutshell, it has 3 components:
1. a kernel driver: you must implement the syscalls
2. a user-space library: you can port
libfuse, or you could implement one with the same API, but uses your own syscalls, that's a possibility too
3. a user-space application that handles the file system (if you did steps 1. and 2. properly, this should compile on your OS without probs)
rdos wrote:
For example, the fatfuse which is part of ubunti (it no longer seems to be available as an independent project) has a lot of problems.
There are many other fat-fuse implementations:
this or
this etc.
rdos wrote:
It actually can only be used by mounting a file in the local filesystem, and then normal file operations are used instead of a read/write sector interface that would be expected if real hardware was used.
Not really, the whole idea behind UNIX's everything is a file philosophy is that you can access block devices as a file. So while the fuse application using open/read/write/close syscalls, if it uses them on a block device, the kernel will actually translate those to sector reads/writes. Note: the same works for Win32, there you have to open the block device \\.\PhysicalDisk\X, and then you can use ReadFile and WriteFile.
rdos wrote:
It's not supported by cygwin, and actually no fuse flesystem is part of cygwin, and so testing it would require a real Linux box.
Try out some other drivers, maybe one will compile out-of-the-box.
rdos wrote:
Another problem is that it is not re-entrant and the code relies on a higher level interface where paths are parsed internally.
Not sure why would you need re-entrancy, but that higher-level interface is the one that libfuse provides, and in all and every fuse driver it is the driver's job to parse the path internally (at least the portion that's inside the image).
rdos wrote:
I think the low-level interface must be used with fuse, but it's up to the implementer to decide which interface to use. That limits the number of possible fuse filesystems.
Not sure what you mean low-level here. There's a simpler interface with fuse_main, and another one fuse_loop. Both should be provided by the library, is this what you mean?
rdos wrote:
Another problem is that there is no ext4 fuse that has write operations, and no Reiser or other complex filesystem.
How about
this one (read-write ext2/3/4)? I've never used raiserfs so I don't know about that.
rdos wrote:
There is an NTFS fues implementation, but one might wonder if this can be reused or not
Most certainly. Ntfs-3g is the best and absolutely portable.
rdos wrote:
So, the question is if FUSE actually adds much usefulness?
I think a lot, it eases the portability significantly. But you have to find the drivers yourself (or write them).
Cheers,
bzt