Xfile: System and Structure

Origins and design.

Get It Try It

Xfile is one of the leading alternative file managers for Apple's OS X.

Origins

Coming to OS X after recently completing a 22 man-month project to write an alternative file manager for Windows, the first thing on one's mind is not to do it all again. But it was obvious right from the get-go on OS X version 10.1.2: Finder simply wasn't ever going to do it.

Developers have lots of files and a big icon display isn't much help. And it's no help either to have to hit ⌘C on a selection, then use the clumsy navigation system to get to another directory, then hit ⌘V to get the files copied. When working with Finder's tabular view things weren't much better. Finder kept separate settings for each directory, meaning navigating to a new directory put one back in the big icon view again. Worse still, Finder couldn't really keep settings well: column widths and sorts didn't stick. Finder's impossible to use.

There was a program provided on the reseller's own CD called SNAX. This was the forerunner to Path Finder. This was a bit better as even 'hidden' files could be displayed (but not by default) but the thing was agonisingly slow. It had a huge splash image which came up on launch and seemed to stay there forever, this because the application had so many image files and frameworks of its own to load.

Speed is a major priority; there's no way a monster like that's ever going to run fast.

We tried an up to date version of the program but it wasn't much better. Perhaps worst of all was how long it took to actually copy files to a new location. Path Finder had no way to force a refresh, so one had to wait until the file system was in the mood to send a notification to the application. This could take 5-15 seconds and it was aggravating to say the least.

It's not an easy step to take, this business of writing a file manager, especially not on a new platform, and yet less than one month after migrating to OS X we began the ordeal, making first headway over the Valentine's Day break.

Design

The difficulty - the concern - with writing a file manager for Apple's OS is that one doesn't have a single system to support. Apple officially support FreeBSD with a MACH kernel but they've also supported legacy file systems and APIs at the same time. The other APIs were nothing we were interested in. Today we see these APIs are being phased out. The system professedly was a Unix system and so Unix had to be the way to go. In fact, if it hadn't been Unix none of us would have made the switch.

And yet there are anomalies with Apple's (lack of) approach: it's not just that there are separate parallel APIs that do the same thing. It's also that there are things about an Apple system that don't really fall into the Unix category.

Xfile was built so that the guts of the program - the 'model' - was totally Unix but with a 'view' (user interface) totally in Cocoa/NeXTSTEP. Should the day come we'd want to port the application to another Unix platform we'd need only rewrite the user interface layer.

Yet this leaves other things out in the cold. Resource forks and Finder info are not part of a Unix system. And yet developers are going to want to control them as well. Putting this logic in Xfile would have destroyed the program's philosophy. So tools to deal with these other exigencies were therefore kept separate.

Ancillaries

Some of the things particular to this platform that have to be addressed by ancillary applications.

• Blue sizes. All Xfile applications display file sizes in an 'off-colour' (blue) when cruft of any kind is attached to them. The ACP system file info sheet shows the sizes of each part of a file.
• .DS_Store. You can't really handle these well from a GUI because they're not attached to files - they're files in their own right (unfortunately). Unless you pick an alternative file manager that doesn't drop them all around in the first place. To get rid of them you need a script such as provided by CLIX.
• Clearff. The first basic 'cruft cleaner'. Simple display. Cleans all extraneous stuff off files dropped on it.
• BBC. The 'Beige Box Cleaner'. Shows more information so you see exactly what you're going to remove. Can also work recursively, drilling down through directories.
• Forker. Forks and 'unforks' files. Superseded by Xattr.
• xabatch. A finely tuned method to remove what today are called 'extended attributes' - or for that matter to add them. This includes Finder and resource fork cruft or anything you want. Works at blazing speeds with xargs.
• Xattr. Also deals with extended attributes but on an individual file basis. Can instantly remove all extended attributes from all open files.
• FileInfo. Edits 'Finder info' for either files or directories.
• Catinfo. Similar to FileInfo but here you see the full 'catinfo' data structure as returned by the HFS APIs.
• Undercover. Written specifically for the iPod crowd. Could Apple could have sold the iTunes store idea to the Big Four without a way to make the default file manager hide things on disk? That's what the Big Four didn't want - file sharing with the iPod. Undercover makes your song collection (or anything you want) visible in any file manager - or alternately hides it again.
• TMI. 'Too Much Information' - spells out what all the various file system attributes mean in plain language. Also includes important system structures for the professional.
• Xattrib. Manipulates the same data as the system info sheet but uses explicit terminology rather than the more arcane octal and hexadecimal notation.
• GDE. Goes where no other file manager has gone before. Comparable in depth to the 'Red Pill' version of Xfile.
• Tracker. The ultimate utility for keeping tabs on what new software (or anything or anybody) is doing to your file system. One of a kind.

You can see a full listing of Xfile's ancillary applications here.