What is FUSEOFS?
The idea of FUSEOFS is to have an Object File System (OFS) on top of FUSEObjC.
While FUSEObjC itself is object oriented in a way, you need to implement a
delegate and a number of specific FUSE related methods in order to implement your
concept of a filesystem. With FUSEOFS you rather implement a very narrow set of much
more abstracted methods on any object, which, in doing so, automatically can be
exposed as filesystem objects.
What is the general principle behind that?
The general idea is to break down all the underlying calls of the filesystem into two things:
- a lookup of objects
- applying the request to the resulting object of that lookup via a method.
How do you get at the data?
FUSEOFS implements the following categories on NSObject which deal with filesystem requests:
- lookup
- - (NSArray *)directoryContents;
- - (NSData *)fileContents;
- - (NSString *)symbolicLinkTarget;
- attributes
- - (NSDictionary *)fileAttributes;
- - (NSDictionary *)fileSystemAttributes;
- MacOS X specific attributes
- - (NSDictionary *)finderAttributes;
- - (NSDictionary *)resourceAttributes;
- reflection
- - (BOOL)isDirectory;
- - (BOOL)isMutable;
Every object derived from NSObject can instantly act as a filesystem
object. Several methods are very easily implemented (i.e. reflection methods)
as these are used in different contexts as well. Also, some of these methods
are mutually exclusive (directory vs. file) and only one or the other needs
to be implemented.
Special semantics like those for the Finder on Mac OS X are implemented in
separate methods. If your objects don't support any of these, you don't need
to implement them - your objects still inherit the default implementation
after all.
FUSEOFS already provides default implementations for various basic objects,
namely:
- NSString, NSMutableString
- NSData, NSMutableData
- NSDictionary, NSMutableDictionary
- NSArray, NSMutableArray
It turns out you don't even need to have more than this to implement a pretty
basic memory filesystem! NSString/NSData represent files, NSDictionary/NSArray
are able to represent directories. It's that simple.
How do you get at the objects?
The only mystery to solve now is how the structure of the filesystem gets
implemented. The concept of FUSEOFS is to implement just a single method:
- - (id)lookupPathComponent:(NSString *)_pc inContext:(id)_ctx;
Every filesystem path, i.e.
/foo/bar/baz is broken down in its path
components, i.e.
- foo
- bar
- baz
If you implement your filesystem, you just need to provide a root object and
implement the method above for this object. The first path component,
foo, is what your root object needs to lookup. Its result is another
object (or
nil if the lookup produced no result) which gets the
request for the next path component,
bar and so on. The last
resulting object in this lookup chain is then asked for its fileContents or
finderAttributes, depending on the underlying request. However, that's all
there is to implement a filesystem in a highly object oriented way!
It goes without saying that this way it's almost trivial to implement
filesystem semantics to any existing backend, i.e. IMAP or LDAP servers.
How does it all blend in with MacFUSE?
FUSEOFS provides a delegate implementation for FUSEObjC, named
FUSEObjectFileSystem which does all the lowlevel stuff to map
FUSEObjC's requests to the objects in FUSEOFS. When implementing your own
filesystem, you should subclass from FUSEObjectFileSystem and
provide your own root object for the lookup mechanism and possibly adjust
the properties given to FUSE on startup, although most of the time that's
not necessary.