|Home » Industry Watch (» The Technological » Hall of Monkeys » Heroes Banquet)
Xfile: For 10.4, 10.5, 10.6, 10.7 and Beyond
The only constant so far is the price.
SERI MENANTI (Rixstep) — As of 5 April, Rixstep's Xfile licence now comes with two additional applications at no additional charge. Further applications will be added until the count is close to double. This now applies to all versions of Mac OS X.
The Xfile file manager is only one of 19 file management applications for users of 10.4, 10.5, 10.6, and 10.7. That's before 16 March. Now as of 5 April, the count is up to 21 on all platforms.
The objective is to integrate all currently 30 (thirty) applications into the same package. And although the price for the package may increase over time, those already subscribing to the package will receive the additional applications at no extra cost. As always.
Xfile Pak All Platforms (Before 2011-04-05)
The Xfile Pak started as an even dozen applications and specifically was not supposed to grow over time. But things changed rapidly. The engineers couldn't contain themselves.
The latest addition to the Xfile Pak was the access control list manager ACL which rounds out the field, meaning the Pak thereafter handled all possible file system contingencies on OS X. (ACL is available only for 10.6 or better.)
Xfile Pak All Platforms (After 2011-04-05)
The two additions to the Xfile Pak on 16 March were Bundle and CatInfo. XaBatch will be added 1 August 2011.
Xfile Pak All Platforms (Coming Soon)
Click on any of the icons above to see what the applications do.
Why Use It?
But why use it? Why use Xfile? Why indeed. It's been called the 'standard setter'; it's been called 'supercharged'; users claim you can never go back to 'TF' Finder again. But what does that mean to you in a practical sense - aside from the aesthetics?
Safety. Apple's Finder is at best a 'hodgepodge' - it's a mixture of several conflicting technologies and to be honest it can't always distinguish its left arm from its right in the dark. Potentially destructive file operations don't succeed out of pure luck. The underbody to the file system - the HFS interface - doesn't have 'sanity check' protective code to protect itself. Wayward or bugged API calls - or bugged APIs - are capable of hosing your entire computer. If Apple's Finder stops the damage it's most often out of pure luck.
Xfile takes pains to make sure potentially damaging file operations aren't even considered, much less allowed. Xfile does not - as opposed to that giddy Finder - allow mixed file types on file operations. You can't inadvertently replace an entire folder and its contents with a text file of the same name; you can't replace a text file with a folder of the same name. For that matter you can't replace an ordinary file with a symbolic link file or vice versa. And so forth. You're protected.
It's easier to work with. You'll find you have less scrolling and looking for things. And so forth. Xfile is quite unique across the board in Cocoa applications in being able to retain selections and offset positions on file system refreshes. There doesn't seem to be any other applications anywhere that do this. Try drilling down into big folders and adding, renaming, or deleting files with any other tool. It's very frustrating. This is why Xfile elicits so many smiles once it's put to the test.
Speed. Xfile is as lean and mean as it gets and yet 'speed' doesn't just mean 'wow that was fast' - it also means you don't put up with annoying lags. You don't have to wait half a minute to get an app on screen, you don't have to wait half a minute for an app to decide to do something, you don't have to wait perhaps several minutes for your changes in the file system to show up.
With Xfile things happen instantaneously - and changes to the file system appear immediately in all open Xfile windows.
All. At. Once.
You get everything. Xfile doesn't hold back - it gets you everything that's 'in there' - in your file system - and gets to you so you have control over it. Xfile users never had to worry about copying their songs back from their iPod - there wasn't even a speed bump.
There are lots of funky things going on in your file system all the time. Things you're not aware of. Do you want to remain blissfully ignorant? Or do you want to decide yourself whether you want to learn more or not? Xfile gives you that option - the Finder won't even consider it.
Today's (Leopard's) Finder can't even be called a file manager anymore. It doesn't really manage much at all. You get to see 'colour bits' and view files in an endless 'cover flow' - but how exactly do you go about getting your script files to run? How do you find out why certain files are doing things you don't want and others aren't doing what you want?
How can you understand why your file system behaves as it does if you can't even see where the sticky bits are? And you probably don't even know what a sticky bit is, do you? But they're there - they're on directories all over the place. And you can't see them because your Finder pretends they're not there. Some 'Finder'.
Or how about set ID bits? File permission bits that suddenly trampoline ordinary programs to root level to run? What control do you have over these? Could one of these bits end up hosing your system? It's possible. Do you have any control over it? Not with Finder you don't. With Finder you don't see shit. Each release of Finder gets only worse.
This is what you can't see (or control) with Finder.
|File type||Not 'file type' as in 'TextEdit document' but 'file type' as in 'real file type' - socket, symlink, directory, whiteout, FIFO buffer, block device, character device, regular file, and so forth. Maybe you most often don't want to know this; that's not the point: the Finder has never shown it to you under any circumstances. Consider yourself screwed.|
|Sticky bits||Sticky bits are used today to protect files in commonly accessible locations. Your root directory has a sticky bit; /.Trashes has a sticky bit; /cores has a sticky bit; /Library has a sticky bit; /var/tmp has a sticky bit; /Volumes has a sticky bit. And if you didn't know that it's because you've been using (and trusting) your Finder. Finder has never accessed sticky bits. Odds are it simply can't.|
|Set ID bits||Set ID bits allow unauthorised applications to run at a higher privilege level than would ordinarily be permitted. They can be quite indispensable but if misused can be extremely dangerous. You have never had control over set ID bits with Finder.|
|eXecutable bits||Discussed elsewhere at this site, Leopard's Finder made the final leap into the world of ridiculousness by now eliminating the ability to control the executable bit in file permissions. Without this bit you can't make a shell script run. If you can't see this bit in file listings you can't possibly see what ordinary files are in fact set to run. Your Finder leaves you a crippled sitting duck.|
|Symlinks||Finder won't even call them by their proper name. It calls them 'aliases' which they are not. Finder won't let you create them either. Symlinks are 'symbolic links' which are a Unix file type unto themselves. They simply contain a path to another file - no more.|
|Hard links||Finder would prefer you didn't even know these existed: the HFS implementation of Unix hard links is shambolic at best. It's never worked right. Developers and users still cannot enjoy the benefits of hard links. And Apple dare claim they are using the 'rock solid foundation'. And you probably didn't even know that. A file manager should offer you the opportunity to create hard links. Xfile does.|
|Extended flags||The kind of thing you'll see in Xattrib, the kind of thing you can edit directly in Xfile. These 'file permission flags' fall outside ordinary file permissions and override (veto) them. Some are so indelible you have to reboot into single user mode to have them removed. Did the Finder tell you about these? Flags like user no dump, user immutable, user append, user opaque, user no unlink, user hidden, system archived, system immutable, system append, system no unlink, system snapshot? Did Finder think you were too stupid to understand them? Xfile doesn't think you're stupid. Outside the Finder's kiddie pool you get the option to do what you want - not what you're told.|
And so forth. Xfile might not be your permanent (or only) 'file manager' if you're not a professional - if you're not a programmer or network administrator. You might need to do 'image browsing' from time to time (which is about all Finder's good for these days). But all users, no matter profession, need to take proper care of their computers and file systems.
ACP: ACP Homepage
ACP: Test Drive Xfile!
ACP: The Xfile System