Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch

Xfile 2012

Achieving parity.


Get It

Try It

RẠCH GIÁ (Rixstep) — As of 29 December 2011, Rixstep's Xfile licence is achieving parity with the ACP applications dedicated to OS X file management. This now applies to all versions of Mac OS X.

The Xfile file manager was one of 19 file management applications. As of 5 April, the count was up to 21, and as of 29 December, the count is up to 26 for 10.4 and 10.5, 28 for 10.6 and 10.7.

The objective was 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. The final applications should be added Q1 2012.

Xfile Pak All Platforms (Before 2011-04-05)


ACL

Clipothèque

CLIX

FileInfo

MD

Rixcomp

Rixmode

Rixstamp

TMI

Tracker

Undercover

Xattrib

Xfile

Xfind

Xscan

Xsed

Xshelf

Xstamp

Xstrings

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)


ACL

Bundle

CatInfo

Clipothèque

CLIX

FileInfo

MD

Rixcomp

Rixmode

Rixstamp

TMI

Tracker

Undercover

Xattrib

Xfile

Xfind

Xscan

Xsed

Xshelf

Xstamp

Xstrings

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 (After 2011-12-29)


ACL

Bundle

CatInfo

Clipothèque

CLIX

FileInfo

Forker

GDE

MD

Rixcomp

Rixmode

Rixstamp

Swap

TMI

Tracker

Undercover

Xabatch

Xattr

Xattrib

Xfile

Xfind

Xrename

Xscan

Xsed

Xshelf

Xstamp

Xstat

Xstrings

The tally will be 32 when the final apps are added. 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 typeNot '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 bitsSticky 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 bitsSet 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 bitsDiscussed 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.
SymlinksFinder 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 linksFinder 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 flagsThe 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.

See Also
ACP: ACP Homepage
ACP: Test Drive Xfile!
ACP: The Xfile System

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.