Question

I want to programmatically change the volume icon for a stacked file system implemented using OSXFUSE (formerly MacFUSE). The icon needs to reflect the state of a mounted file system.

The approach that I have been trying to get working is to map requests for /.VolumeIcon.icns to the appropriate icon in the application bundle. Then sending change notifications to the file system for the actual path (path) and the mount path (mountPath).

    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: @"/Volumes"]; 
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: [mountPath stringByDeletingLastPathComponent]];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: mountPath];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: [path stringByDeletingLastPathComponent]];
    [[NSWorkspace sharedWorkspace] noteFileSystemChanged: path];

    FNNotifyByPath([[[mountPath stringByDeletingLastPathComponent] dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);
    FNNotifyByPath([[[path stringByDeletingLastPathComponent] dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);
    FNNotifyByPath([[@"/Volumes" dataUsingEncoding:NSUTF8StringEncoding] bytes], kFNDirectoryModifiedMessage, kNilOptions);

Stepping through the debugger I can see this code being hit but the code to map the /.VolumeIcon.icns gets called infrequently and never in response to these notifications.

Answer 1

I think the short answer is, you’re out of luck. The long answer is while the OSXFUSE project is different than the Fuse4X project, they’re both derived from the same source, and Fuse4X has this to say about volume icons in their FAQ:

Q 4.1. Why do Fuse4X volumes show up with “server” (or “network
volume”) icons?

A: To be precise, by default Fuse4X volumes show up as nonlocal
volumes, which the Finder unfortunately treats the same as “servers”.
It’s a good question as to why Fuse4X normally tags its volumes as
nonlocal. Some people think that in the case of disk-based file
systems, Fuse4X must tag the volume as local. Well, let us see.

For a vfs to be local on Mac OS X, you need a “real” disk device – a
/dev/disk* style node. Such a real disk device node in Fuse4X’s case
is problematic: at mount time, for a local volume, the kernel would
itself open the device node and pass it to Fuse4X. In doing so, the
kernel would make sure that the device is not currently in use (for
one, to disallow multiple mounts of the same device). This happens
before control passes to Fuse4X and mounting can proceed. This would
have been fine if the entire file system lived in the kernel, but in
Fuse4X’s case, the user-space file system program would also want to
(exclusively) open the disk device.