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.

The general idea is to break down all the underlying calls of the filesystem into two things:

1. a lookup of objects
2. applying the request to the resulting object of that lookup via a method.

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.

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.

1. foo
2. bar
3. 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.

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.