Volume Number: 23 (2007)
Issue Number: 03
Column Tag: Source Hound

MacFUSE: The Man Behind the Mask

Interview with Amit Singh

by Dean Shavit

Once in a while, an Operating System Event occurs which has the potential to drastically change the user experience for everyone who works on the platform. Sometimes these events are "ah-ha" events, such as the preview of Time Machine for Leopard at WWDC, where the normally complex and tiresome task of daily backups and recovery of lost files and folders blossomed into something both sensible and fun. The release of NeoOffice (http://neooffice.org), an aquafied port of the Open-Source OpenOffice suite in spring of 2005, also heralded a major event in the story of Mac OS X.

Some events take a while to unfold or find their niche or hang around for a while then pick up steam to suddenly become real assets. The Growl project (http://www.growl.info) turned the mundane and cumbersome "jumping icon" user notification for applications into an elegant, translucent, and customizable badge of information for those application developers that didn't necessarily want to write our own notification systems or rely on Mac OS X's clunky leaping icons. In a similar vein, the Sparkle project (http://andymatuschak.org/pages/sparkle) has rapidly assumed the vacant position of software update engine of choice for independent developers.

Many of these voids in functionality create vacancies that developers for Mac OS X can occupy or thrive in, given the right vision, implementation, or something as simple as good timing. Last year, when researching the "Mac Tech 25" most influential technical professionals, I said: "Someone has to wear the crown of top Mac OS X Hacker, and no one who has visited Amit Singh's website--http://www.kernelthread.com (now superseded by www.osxbook.com) would argue otherwise."

The "crown" in question here is not just euphemism bestowed lightly for the sake of good reading but a title earned. As if his 1600 page study "Mac OS X Internals: A Systems Approach" wasn't enough of a contribution to the Mac OS X technical community, Amit surprised us -- no, stunned us -- yet again with his presentation "Taming Mac OS X File Systems" at MacWorld where he unveiled MacFUSE.

Between Amit's initial presentation and the time this article is printed, MacFUSE has already been updated several times, and is now distributed on a disk image with a double-clickable installer. Super-geeky technology aside, MacFUSE, at least in terms of function, is best understood by watching Amit's video presentation about the possibilities linked here: http://code.google.com/p/macfuse. Even though many of the filesystems he demonstrates are working (and unreleased) prototypes, it's not hard to see why rssfs (the ability to browse, organize, and sort rss feed:// URLs as if they were files in a folder, and launch them by double-clicking) or iofs (which shows kernel events as a browseable file system) are just downright cool and useful.

Even so, currently working and fully supported FUSE filesystems for Mac OS X include sshfs (a read-write volume mounted on your desktop via ssh) ftpfs and ntfs-3g (allowing for read/write NTFS � such as a normally read-only Boot Camp partition). Initially, the prospect of mounting a file system using sshfs normally accessed through other means (such as the command-line) might leave some end users scratching their heads wondering why they would want to do that ... but certainly not the developers who've spent a great many hundreds of man-hours building GUIs for scp, sftp, or ftp (just look at Cyberduck and Fugu). Now, developers get mountable and encrypted read/write filesystem capabilities with the installation of one free (and Open-Source) package.

An Interview with Amit Singh

I had many questions about the technology behind MacFUSE, and what prompted Amit Singh to bring it to Mac OS X. I decided to ask him those questions directly. Amit's reputation is that he's "ridiculously brilliant" when it comes to computer operating systems and so naturally I had some trepidations about not being well prepared enough to engage in such a dialogue with him. I have to say, though, that my anxiety was entirely unfounded. Not only does Amit know how to code, he also knows how to communicate, something I'd learned from reading his articles on his site, http://osxbook.com. What I wasn't prepared for was his ability to explain things at my level in a perfectly understandable way and with a rare gentleness where others might be mocking or arrogant. What could have been painful for me was made a pleasure, and I learned that Amit's motivation in learning and improving Mac OS X may well stem from his desire as a Mac OS X user to do his own work more effectively.

Dean Shavit: As Open-Source editor for MacTech, I often try to write articles focused on what some would call "Force Multipliers" or "Enablers," in other words those Open-Source projects that add value or capabilities to Mac OS X with easily-understandable and accessible APIs. I think that MacFUSE is destined to become such an enabler.

Amit Singh: Thank you. I hope so too. So far, response to MacFUSE has been uniformly positive. People seem to find it both useful and "cool", and something that was sorely missing on Mac OS X.

Dean Shavit: Well, let's not waste any time then *grin* I think that Mac OS X is short on file system support, and that the learning curve to produce such support has (without a tool like MacFUSE) been prohibitive, perhaps even for Apple's own engineers! In the five years I've been using the platform, I've not noticed much progress in the way of file systems other than the enhancements to HFS+ (extended attributes and journaling) and read-only NTFS. I've seen an Open-Source kernel extension to support Linux ext2 (http://sourceforge.net/projects/ext2fsx), but that's really only to read external drives or drives pulled from Linux systems. So, how did you arrive at MacFUSE as a possible solution to this shortfall in filesystem support?

Amit Singh: Writing file systems (the traditional way) is super hard--essentially black magic, regardless of which operating system you are on. A few months ago (after WWDC 2006), I had been thinking of things that would be really nice to have on Mac OS X but were missing. Two things were near the top of my list: a FUSE-like mechanism and DTrace. Apple took care of the latter, so I thought I might give the former a shot.

Dean Shavit: Well I don't know if it was intentional on your part, but over the years, your interest in Mac OS X seemed to have focused both on the kernel and Mac OS X filesystems, with great utilities like HFSDebug and of course your book "Mac OS X Internals" So MacFUSE, which combines kernel expertise and filesystem expertise seems like a logical outgrowth of your work over the years. Did you attend WWDC? I was pretty disappointed that you weren't speaking at the conference. I also noticed (when visiting the Apple Campus Store) that two shelves were dedicated to your book. The folks at the store said that they couldn't keep 'them in stock!

Figure 1. "Mac OS X Internals"

Amit Singh: I did attend WWDC 2006--the first Apple conference I ever attended. As for the book, I'm glad that it has been well received. There can be no bigger reward for a technical author than to see people find their book useful and/or interesting. My interest in Mac OS X ... that's just a manifestation of my interest in operating systems. I've been similarly interested in other systems, just not to this extent I suppose.

Dean Shavit: Well that interest certainly shows in your work, but especially in your writing. Was that part of the reason you moved to Google from IBM, so you could work with Mac OS X?

Amit Singh: Oh no, not at all. My move had nothing to do with Mac OS X, and I was in fact not on the Macintosh team for my first several months at Google. Conversely, I worked on some Macintosh stuff even at IBM. Like I said earlier, my deeper interest is in operating systems. Mac OS X just happens to be rather convenient because that's what I use, too.

Dean Shavit: Well we're certainly glad you're on the Google Macintosh team now! Have you ever participated in writing a file system (the traditional way?) for any Operating System?

Amit Singh: I've written experimental file systems for Linux and Solaris.

Dean Shavit: Was MacFUSE your first attempt at a kernel extension?

Amit Singh: You mean for Mac OS X?

Dean Shavit: Yes, but if you've written others, were they for Microkernels?

Amit Singh: No. "Mac OS X Internals" has some examples of kernel extensions. I've also released other kernel extensions for Mac OS X (like the TPM device driver and the /dev/kmem driver). [T]his one isn't for a microkernel either -- you aren't implying Mac OS X uses a microkernel, are you?

Dean Shavit: I thought it did, and it seems to be an accepted notion, but if I'm wrong, tell me why...

Amit Singh: Well, let me ask you -- why do you think it uses a microkernel? Is it because of the Mach connection?

Dean Shavit: It's just the way I read the Mac API reference docs. To quote "Mac OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF's commercial development efforts were incorporated into Darwin's kernel."

Amit Singh: Let me quote something from page 50 of "Mac OS X Internals"…

"Mach is often unequivocally equated to a microkernel, but as we saw in Chapter 1, it was not until version 3 of Mach that it was used as a true microkernel. ... Even though Apple uses a Mach implementation that derives from Mach 3, xnu does not use Mach as a microkernel. Various subsystems that would be implemented as user-space servers in a true microkernel system are part of the kernel proper in Mac OS X. In particular, the BSD portion of xnu, the I/O Kit, and Mach, all reside in the same address space."

Apple's kernel only uses code that comes from Mach--it is not a microkernel at all.

So your question becomes: "Why doesn't Apple use a microkernel?"

Dean Shavit: OK....

Amit Singh: Well, short answer: they just don't! In a commercial operating system, adopting a kernel is a long-term deal ... you can't just go on changing your kernel architecture across releases ... Apple went with the NEXTSTEP heritage, and that's just how it is.

Dean Shavit: In a microkernel OS, would it have been more difficult or easier to implement FUSE?

Amit Singh: It would have been a bit easier in some areas.

Dean Shavit: Have you ever worked with a Microkernel-based OS?

Amit Singh: A few: GNU HURD, Minix, and a bunch of academic systems. These days, "monolithic" systems are not as monolithic as they used to be. Just like how RISC and CISC processors adopted each other's features over time, "monolithic" systems tried to be not so monolithic too.

Dean Shavit: I understand. I'm going to guess the reason that MacFUSE requires Mac OS X 10.4 is because Apple published a KPI designed to formalize some of these interfaces.

Amit Singh: Yes, before 10.4, writing a file system for Mac OS X was much more painful

Dean Shavit: So FUSE is a filesystem in its own right, with it own extensions...

Amit Singh: Yes, MacFUSE looks like a regular file system to the OS X kernel. It frees you from having to worry about everything else except the data that you want to provide from your user-space file system.

Dean Shavit: Right, I've seen it at /dev/fuse

Amit Singh: Yes, although /dev/fuse here doesn't work like a disk device. MacFUSE uses /dev/fuseN devices for kernel-user communication.

Dean Shavit: Since I started investigating FUSE and using MacFUSE, I've thought that the notion of "File Systems in User Space" was a bit misleading, as you do need kernel level support first, and that's what you've given to the Mac OS X community. I'm already using sshfs for web development, though my attempts at using it for an iTunes library weren't as successful. There must be an overhead/performance penalty for the ability to load these in userspace... I found that the data stream would stop and start, whereas using AFP over a VPN didn't have that issue.

Figure 2. MacFUSE Archtitecture from Amit Singh's MacWorld 2007 Presentation "Taming Mac OS X Filesystems"

Amit Singh: MacFUSE itself doesn't have a huge overhead--much less than what one would tend to imagine. sshfs, the user-space file system, is more of a utility file system right now than a general purpose file system. The other thing, which I see as a bit of a problem, at least initially, in the Mac OS X world is that MacFUSE (and things like sshfs) have too many "knobs". Meaning, too many options and things you can tweak.

Dean Shavit: I'm beginning to find that out. I love being able to mount a directory on any folder instead of pre-defined shares. But I like the knobs! But I also know a few folks who want to write GUIs for sshfs as well...

Amit Singh: Just by its nature (it can support any type of user-space file system), there's not one set of reasonable defaults.

Dean Shavit: Please please please don't cut down on the command-line options!

Amit Singh: I think it's important in the Mac universe to not expect users to be well versed with these knobs -- no no, I am not talking about taking them away, just that I find people asking for features that are already there.

Dean Shavit: Some will find it way too geeky for them, but that's life --as if ssh and openssl didn't have a zillion knobs on their own. Leave it up to us hybrid developer/sysadmins to create reasonable GUIs for these FUSE filesystems.

Amit Singh: My personal experience with sshfs has been quite good--I do use it for playing QuickTime video.

Dean Shavit: On a local network or over the internet?

Amit Singh: My experience is on a LAN. Plus, playing songs (in your case) doesn't even sound like a lot of throughput requirement.

Dean Shavit: Agreed, it should work for me; maybe I need to turn a few knobs.

Amit Singh: Also, please just ditch the existing release when 0.2.0 comes out.

Dean Shavit: Another thing -- I am having a bit of a tough time navigating through the MacFUSE project. Let me explain.

Amit Singh: OK.

Dean Shavit: First, the Google Code pages aren't what I'm used to when it comes to working with an Open-Source project -- they take a bit of getting used to. Second, it's not entirely clear to me where your (and Google's) involvement in the MacFUSE project begins and ends.

Amit Singh: Well, as far as I'm concerned, MacFUSE is just the core (the kernel extension, the user library, and the internal mount utility, etc.)

Dean Shavit: For example, just now you mentioned that you had some concern about sshfs being more user-friendly....yet in reality, the MacFUSE project really ends in with the kernel-level support, right? Or do you and Google intended to take on support, and source code management for the binary builds for FUSE?

Amit Singh: This being a part-time project, there simply aren't enough cycles for me (or anybody else on my team) to support all kinds of file systems.

Dean Shavit: Understood.

Amit Singh: We did it (so far) to get people jumpstarted.

Dean Shavit: That makes perfect sense to me.

Amit Singh: You might have noticed that I'm moving all sshfs related issues to a new status on the project page: "NeedVolunteer" And fortunately, people are stepping up!

Dean Shavit: Well consider me one of the volunteers; I'll do what I can!

Amit Singh: Thanks, and we'll help you every way we can.

I'm under no illusion that just having a solid and robust core (the kernel extension) will make users happy! After all, this *is* the Mac universe. People have been demanding better UIs since day one.

Dean Shavit: Don't I know that, but after a while, the ROI for small single-purpose GUIs isn't always worthwhile. For example, I love your command-line tool "HFSDebug" but I don't see any reason to write a GUI to expose every "knob" to the end-user.

Amit Singh: Also, like the demos I showed (not sure if you have seen the video), the file system just becomes an application that you launch.

Dean Shavit: I have seen the video. [Note: the video is a must-see, and is linked off the main MacFUSE project page]

Amit Singh: Technically, we aren't maintaining the user library either. I only released a patch that you apply to the library available from the FUSE web site. What would also be useful on Mac OS X is, say, an Objective-C "wrapper" library on top of the Unix-style libfuse.

Dean Shavit: I'm also thinking that the effort to support MacFUSE filesystems should start at the project level to add direct support for configuring and compiling filesystems on Mac OS X into the existing projects that currently only compile on Linux.

Amit Singh: Oh, I didn't say I'm not maintaining the *patch* Release 0.2.0 will have a patch for 2.6.3.

Dean Shavit: I know one of the things I found a bit unclear when I went to compile MacFUSE was if I should be using the new libfuse or 2.6.1. It would help if that were listed under system requirements.

Amit Singh: When compiling from source?

Dean Shavit: Right, your exact words "Suppose you downloaded fuse-2.6.1.tar.gz." At the time, both 2.6.2 and 2.6.3 were available. So I had to guess.

Amit Singh: Right...thanks for your feedback.

At this point though, the binary package is really the preferred way to install.

Dean Shavit: Does installing the binary allow for folks like myself to compile FUSE filesystems?

Amit Singh: The binary package gives you the FUSE user-space library (libfuse) and the header files. If you're writing a new file system just for Mac OS X (that is, you don't care if it's portable), there's no reason to use libraries that don't exist already on Mac OS X, so you should be fine. Some Linux FUSE file systems do need things that don't exist on Mac OS X by default, so you have to go find those dependencies first.

Dean Shavit: And that's where I'm having some trouble.

Amit Singh: The very first MacFUSE binary tarballs contained the most common of these dependencies (glib), but that was a maintenance nightmare for us.

Some people didn't want those binaries, some wanted them in different locations (because some use Fink, some use MacPorts, some compile their own stuff)

Which is why I decided to just focus on the "Core". Because that's what benefits people the most in the long run (if that's robust and featureful).

Dean Shavit: On my main development machine, I couldn't get anything to compile because of conflicts with both FInk and MacPorts (formerly Darwinports). When I started with a clean install, I was then able to "attempt" to compile some filesystems from Linux, but with no successes yet.

Amit Singh: Which file system were you trying to build?

Dean Shavit: I tried CopyFS and wayback as well, sometimes referred to as "the poor man's Time Machine."

Amit Singh: I think those two (and some others as well) are among the ones that have way too many external dependencies

Dean Shavit: As I see it, there's going to be three main types of users for FUSE:

First, there's gong to be application developers who will want to write their own FUSE filesystems. I can think right away of one company (Delicious Monster) that would see an immediate benefit � by allowing users to browse and open books, DVDs, and other catalog items from the Finder that were published in Delicious Library. Also, there's a class of aggregation or notebook software solutions such as Circus Ponies Notebook or Yojimbo that act as a place to "throw" images and text snippets for better searching. I think having MacFUSE available will result in some pretty cool implementations in the next twelve months if developers like the ones I've mentioned decide MacFUSE will help their products.

Amit Singh: I agree.

Dean Shavit: Second, there's the group that I belong to, the "hybrid" sysadmin / developer who may write AppleScript Studio interfaces or Cocoa interfaces to command line tools. For us, we're going to be looking to MacFUSE for things like backup, remote access, system monitoring, access to drives and disks from other OSes and possibly workstation management. We're going to be the group most likely to want MacFUSE to support MacPorts of Fink for its implementation of pkg-config, and we're also going to be the ones who are going to need things spelled out a bit more than the devs.

Third, there's end users who should only see the benefits, not the knobs. But right now, there's not much for them.

Amit Singh: Yeah, that sounds about right.

Dean Shavit: I'd like to see the Google Project Page for MacFUSE offer three links, one for each audience.

Amit Singh: It hopefully will, in due time.

Dean Shavit: So yes, I've had some trouble compiling Linux file systems, but I also want to write one. I have an idea for one that you could probably finish in a hour, but that would take me weeks.

Amit Singh: Sure. [I] just want to point out that Google has been wonderful in letting me work on this, and then letting me release this as open source. Still, at least as far as the MacFUSE Core part goes, it's pretty much a one person "personal" project, which means whatever time I get to work on it, I have to use it judiciously. This is also why community involvement is so critical.

Dean Shavit: Yes, kudos to Google for giving you the time to pursue MacFUSE, I'm sure that Google also might be among the first to use it for its own Mac OS X Software! With all of the Web 2.0 development that Google's currently working on, it makes a lot of sense to bring that data down to the desktop as a mountable filesystem for the end-user. About developing for MacFUSE, somewhere in fuselib there's a method to take a list of posix paths and convert them to a file system...

Amit Singh: Which method? do you remember?

Dean Shavit: I am just guessing based on what I've seen, hang on....Let me have a peek at the source…Well the docs say that your arguments are passed form your user mode program to fuse_mount() and fuse_main(), so either I have to bone up on the API or look at an example.

Amit Singh: There's an example file system in the source of FUSE 2.6.3: fusexmp.c.

Figure 3. Fuxsexmp.c from FUSE source code.

Amit Singh: That acts as simply a wrapper atop your regular file system. Fusexmp can be a good starting point for a MacFUSE file system.

Dean Shavit: The idea I have is called "pkgfs" that would allow someone to mount /Library/Receipts and browse the contents of the BOM files as links, thereby navigating to the files when clicking on them.

Dean Shavit: So I'd have to look into adapting fusexmp.

Amit Singh: I think looking at hello.c and fusexmp.c both should get you started. Fusexmp has all the methods you'll need and hello.c has an example of how you can generate a file on the fly.

Dean Shavit: What does it do?

Amit Singh: it remounts your root on another directory. It's just a pass-through file system. So I say "fusexmp /tmp/foo", and now /tmp/foo/ contains what I have in /, so I can even go /tmp/foo/tmp/foo (recursively), not that that's a good idea…*grin*

Dean Shavit: So a listing in POSIX path form could easily be passed as a filesystem, makes sense to me.

Amit Singh: Yup.

Dean Shavit: OK, that brings me to my next question. Once you've presented a mountable filesystem, there's all sorts of other factors that come into play, such as directory services, extended attributes, ACLs, re-sharing file systems over a network, etc. How have you been able to adapt MacFUSE to Apple's unique file system and extended attributes and directory services. Have you investigated re-sharing an sshfs mount over AFP, for example?

Amit Singh: With release 0.2.0, MacFUSE supports ACLs ... it already supports extended attributes (and has better support in 0.2.0). It's quite nice actually: if your user-space file system implements extended attributes, MacFUSE will let it handle them. If not, MacFUSE will handle them for you as Apple Double ("._") files. So you can right away, with sshfs or whatever, enable ACLs, use apple's tools to set these ACLs, and have the ACLs come into effect.

Dean Shavit: The fact that you would go through the trouble to support ACLs makes me think that MacFUSE might have a future in the enterprise computing arena.

Amit Singh: Well, I did it because it seemed like a natural thing after I put in extended attributes support. (Apple stores ACLs in extended attributes)

Dean Shavit: That's really incredible. It opens up all sorts of possibilities.

Amit Singh: Similarly, MacFUSE also supports kevent/kqueue now and it already supports fsevents (the notification mechanism that Spotlight uses) and Kauth (the kernel-level notification mechanism that virus scanners use). So it really supports a whole lot of things that way.

Dean Shavit: Gosh, wouldn't it be nice to be able to *mount* your quarantine folder as a separate filesystem....I read your release notes, and was intrigued by the mention that kqueue and kevent use an "unsupported Apple API" does that mean undocumented or unsupported like a menu extra vs. a menulet extension?

Amit Singh: No, unsupported here means that Apple has put it in an umbrella called "unsupported" (in the kernel interfaces section) ... either Apple will not take this interface away, and if they do, it will be to provide a better interface

So it's "supported" in that MacFUSE is not intercepting any functions or patching memory etc. It's just that apple has earmarked this particular (kevent/kqueue) thing as something that "could go away in future."

Dean Shavit: So MacFUSE is not performing any code injection, or relying on any undocumented kernel interfaces?

Amit Singh: No, not at all. Well ... it's ironic ... but a lot of the "documented" stuff is "undocumented" in the os x kernel ... so I find your question amusing *grin*, meaning, it's /supported/, but Apple hasn't had the time to document it.

Dean Shavit: That's great, I'm sure many people who have heard of MacFUSE have wondered if that's the case. That means that forward-compatibility is almost 100% guaranteed for Leopard and beyond, till Apple drastically changes its KPI.

OK, so here's a question: other than yourself, how many developers can navigate the uncharted kernel space? There must be a handful outside of Apple. I did notice that Apple referred back to the mklinuk project for more elaborate documentation for MACH! Did you ever work with mklinux?

Amit Singh: I've played with mklinux, but it was much "before my time."

Dean Shavit: So, is much of the work with the support but undocumented kernel APIs trial and error, or is there a logic to it?

Amit Singh: No no ... it's even documented that "please use these interfaces" -- that much is documented. Apple just hasn't had the time to describe them (like systems like Solaris and AIX have -- voluminous kernel documentation)

So there's nothing kludgy or hacky here. Besides, that's one reason why I wrote "Mac OS X Internals" -- I believe people should find that useful for kernel work.

Dean Shavit: Right, but how did you "discover" that information?

Amit Singh: Oh ... that's just studying the system ... I do operating systems for a living, after all, so it's just "work"

Dean Shavit: So was that a lot of ktracing and memory dumping? Which tools did you rely on?

Amit Singh: Most of what's available on Mac OS X, plus many that I wrote (the source of which is in the book), reading the source, and experience from other operating systems.

Dean Shavit: I remember very well your open challenge to the Mac OS X community to figure out the "PanPipes" and how it exploited a flaw to cause a kernel panic. I thought that was both fun and interesting! The moment I heard about MacFUSE, I thought "this is similar technical challenge, but everyone's going to win."

Amit Singh: Heh ... that's an interesting way to put it. I really do hope people benefit from MacFUSE.

Dean Shavit: If you expose a flaw, many people might learn something. But this time you've exposed what might amount to be a gold mine of file systems. Have you had any direct feedback from Apple engineers about this terrific accomplishment? I know Apple's trying to bring Leopard more into the UNIX mainstream. It seems like FUSE might be a natural fit for that initiative.

Amit Singh: No, I haven't had any MacFUSE-related communication with Apple engineers after we put this out.

Dean Shavit: Well I'm sure they're busy updating Launchd and the binaries for UNIX certification. Have you submitted MacFUSE to MacForge in any formal way?

Amit Singh: No.

Dean Shavit: Do you think Apple would do its own FUSE implementation at any point?

Amit Singh: I can't speculate on Apple's plans. We have release MacFUSE under an open source license, so Apple and whoever else are welcome to do what they please under the terms of the license.

Dean Shavit: It would be much more widely used if it were part of the Mac OS X distribution.

Amit Singh: Right, but that's really up to Apple.

Dean Shavit: However, one of my hats is a journalist's Fedora, so I will speculate that they won't include it unless it picks up a lot of end-user support, and if they do, they'll probably re-write it from scratch, and perhaps build it directly into the kernel.

Amit Singh: Sure, but I don't see why they would rewrite it from scratch.

Dean Shavit: (Fedora off). I don't see why either. Well I for one hope that they take the gift you've given Mac OS X and consider it seriously for inclusion in the OS.

Amit Singh: Apple has very good and very pragmatic programmers.

Dean Shavit: You've had three releases of MacFUSE since MacWorld, and the stability and improvement have been rapid. Is there some point where you'd feel MacFUSE was mostly "done" or is there a list of improvements you're looking to make in the next few months?

Amit Singh: I think with 0.2.0, most of the features I wanted to put in will be there. I expect that I'll be focusing on bugfixes and optimizations mostly, but you never know.

Dean Shavit: And once MacFUSE is in maintenance mode, which other missing capabilities of Mac OS X are you considering bringing to the platform?

Amit Singh: Ah that's hard to say. I always make this resolution that 1) I'll not work crazy hours and 2) I'll give Mac OS X a rest and pursue other areas ... somehow, I always fail to keep the resolution

Dean Shavit: I'm very familiar with #1, but frankly haven't considered #2! Well, thank you very much for your interest in Mac OS X. May you never have time to pursue those "other areas"!

Amit Singh: Thank you for your interest in what I do.

Getting Started with MacFUSE - sshFS

Getting going with sshfs takes just a few minutes.

First, download the lastest binary of MacFUSE from http://code.google.com/p/macfuse/, install it and reboot. Then, put the sshfs application in your /Applications folder. Then, create a directory in /Volumes using the following terminal command:

macbookpro:~ dean$ mkdir /Volumes/mymount

then:

macbookpro:/Applications/sshfs.app/Contents/Resources dean$ ./sshfs-static
mostadmin@www.macworkshops.com:/Library/WebServer/Documents/Macworkshops /Volumes/mymount/
-oreconnect,ping_diskarb,volname=Macworkshops
mostadmin@www.macworkshops.com�s password:
kextload: /Library/Extensions/fusefs.kext loaded successfully
mostadmin@www.macworkshops.com�s password:

The mounted sshfs volume appears, like any other network volume, mounted at the directory specified with the label specified. It's accessible as any other local or network volume on the system.

Figure 4. Mounted sshfs file System.

Getting Started with MacFUSE -- SpotlightFS

Using the SpotlightFS application is a snap. Just download it and create a folder inside the mounted SpotlightFS volume. Any pre-existing Smart Folders will also appear there. SpotlightFS lets you look at your Smart Folders as if they were actual volumes. If you write a script that will follow the symbolic links, you may even be able to back up using Smart Folder selection criteria.

Figure 5. Mounted SpotlightFS.

MacFUSE Resources

The FUSE Main Project page: http://fuse.sourceforge.net/

Filesystems based on FUSE: http://fuse.sourceforge.net/wiki/index.php/FileSystems

MacFUSE Main Project Page: http://code.google.com/p/macfuse/

"Taming Mac OS X File Systems": http://googlemac.blogspot.com/2007/01/taming-mac-os-x-file-systems.html

Amit Singh's Mac OS X Internals Site: http://osxbook.com/

Next Time…

By the time this issue of MacTech hits the newsstands, I should be finished with our current product development cycle (and boy it sure was a long and demanding cycle) and I should be back to writing more regularly. I'm not sure what I'm going to write about, but I have a feeling that MacFUSE may play a part, especially if I decide to write "pkgfs"

---

Dean Shavit is an ACSA (Apple Certified System Administrator) who loves to use a Mac, but hates paying for software. So, he remains on the hunt for the best Open-Source and freeware solutions for Mac OS X. Besides surfing for hours, following the scent of great source code, he's a partner at MOST Training & Consulting in Chicago, where he trains system administrators in Mac OS X and Mac OS X Server, facilitates Mac upgrade projects for customers, and writes for his own website, www.themachelpdesk.com. He also the creator of Mac HelpMate, a widely-used troubleshooting and remote access tool, available at www.machelpmate.com. If you have questions or comments you can contact him: dean@macworkshops.com.