Home » Learning Curve
A Unix Primer for the Mac with XfileTwenty-five years ahead of today.
We won the Mac file management competition long ago with Xfile. The others, the 'also-rans', still plod on, for some reason, still brandishing sluggish ideas paired with questionable performance and of course the totally unexpected crash. Apple's own flagship (some flag, some ship) is of course way out in front here. They keep at it, adding incongruity to what should be simple and solid software. It's the World of the Mac.
A file manager is a tool. It's not a toy. It's a means to an end. It's not a video game. Flashy lights and buttons do not a file manager make. A file manager must be simple, straightforward, and do its job reliably - something the competition never achieve.
Understanding Xfile is a matter of understanding Unix filesystems and vice-versa. Unix isn't difficult - Unix creator Ken Thompson is himself the epitome of simplicity.
Presumably you're reading this because you understand that file management is the cornerstone of Unix (or any operating system).
Before starting, you might want to try the manpage for ls. If you fully grok and grasp that page, you understand everything about Unix.
NAME
ls -- list directory contents
SYNOPSIS
ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]
Another way to look at it - it won't hurt - might be to study the stat struct.
struct stat { /* when _DARWIN_FEATURE_64_BIT_INODE is defined */
dev_t st_dev; /* ID of device containing file */
mode_t st_mode; /* Mode of file (see below) */
nlink_t st_nlink; /* Number of hard links */
ino_t st_ino; /* File serial number */
uid_t st_uid; /* User ID of the file */
gid_t st_gid; /* Group ID of the file */
dev_t st_rdev; /* Device ID */
struct timespec st_atimespec; /* time of last access */
struct timespec st_mtimespec; /* time of last data modification */
struct timespec st_ctimespec; /* time of last status change */
struct timespec st_birthtimespec; /* time of file creation(birth) */
off_t st_size; /* file size, in bytes */
blkcnt_t st_blocks; /* blocks allocated for file */
blksize_t st_blksize; /* optimal blocksize for I/O */
uint32_t st_flags; /* user defined flags for file */
uint32_t st_gen; /* file generation number */
int32_t st_lspare; /* RESERVED: DO NOT USE! */
int64_t st_qspare[2]; /* RESERVED: DO NOT USE! */
};
Stat has everything the system knows about a file, everything there is to know. The fields in that struct show you everything you can do to a Unix file, aside from copying, deleting, and moving/renaming it. All the fields are important to keep an eye on.
The Xfile Toolbar
But we'll approach this topic by going through Xfile's toolbar options. And as we do, we'll have reason to comment and even detour a bit now and then, in order to help you better understand the system's underlying features and idiosyncrasies. All through the prism of Xfile.
(And yes there are gobs of features that Apple won't tell you about.)
 
So here we go. This first part can seem overly formal and repetitive and, yes, boring, but have heart - things get better soon.
The Xfile toolbar.
Applications
This is from the default left side of the toolbar, the section for 'directional' commands. They take you places. (The right side is default for 'edit' commands that do things to files.
Applications takes you to the /Applications directory. Note the forward slash: this is a directory under root.
You can have a lot of directories with that name on your system and in your network.
Paths
-----
NSAllDomainsMask, NSAllApplicationsDirectory
(
"~/Applications",
"~/Applications/Utilities",
"~/Developer/Applications",
"~/Applications/Demos",
"/Applications",
"/Applications/Utilities",
"/Developer/Applications",
"/Applications/Demos",
"/Network/Applications",
"/Network/Applications/Utilities",
"/Network/Developer/Applications",
"/Network/Applications/Demos"
)
But the two most common are /Applications and ~/Applications.
Xfile can also get you to ~/Applications, if you press option ('⌥') as you click.
In general, Xfile directional commands take you somewhere either under root or in your home area. Pressing option as you click will take you to the 'other' one.
Copy
Keyboard: ⇧⌘C
An edit command from the default right side of the toolbar. Starts a file-copying procedure. Select a tree node on the left or a number of items from the right and click. A file-copying sheet will drop down. Navigate to your intended destination and click 'Copy'.
If you press shift as you click 'Copy', Xfile changes to your destination directory on completion.
Delete
Keyboard: ⌘⌫
An edit command from the default right side of the toolbar. Deletes either a tree node on the left or the selections on the right. Xfile reminds you if your selection is on the left.
You have three options on the panel sheet that drops down. You can recycle, destroy, or cancel.
Recycle moves your selection to the default 'Trash' directory, which is simply '.Trash' under your current 'root'. This is an all-too simplistic system. Even though it was Apple who first came up with the idea, Microsoft have a far superior system today. The term 'recycle' dates from the NeXT era.
Destroy really destroys. There's no turning back. No trash. What's destroyed is gone forever.
Desktop
A directional command from the default left side of the toolbar. Takes you to ~/Desktop. As there's no /Desktop counterpart, pressing option does nothing. (/Desktop is still sought out.) Release option and click again to get to ~/Desktop.
Documents
A directional command from the default left side of the toolbar. Takes you to ~/Documents. As there's no /Documents counterpart, pressing option does nothing. (/Documents is still sought out.) Release option and click again to get to ~/Documents.
Downloads
A directional command from the default left side of the toolbar. Takes you to ~/Downloads. As there's no /Downloads counterpart, pressing option does nothing. (/Downloads is still sought out.) Release option and click again to get to ~/Downloads.
Duplicate
Keyboard: ⌘2
An edit command from the default right side of the toolbar. Duplicates the selection in focus on either the left or the right. Names are appended with 'copy', 'copy 2', and so forth. Hooks into legacy NeXT code. Has the handy shortcut '⌘2'.
Favorites
A directional command. Takes you to ~/Library/Favorites. This directory may not exist.
As there's not normally a /Library/Favorites counterpart either, pressing option does nothing too. (/Library/Favorites is still sought out.) Release option and click again to get to ~/Library/Favorites (if it exists).
Folder
Keyboard: ⇧⌘F
An edit command from the default right side of the toolbar. Creates a directory under the current working directory. Focus must be on the current working directory on the left. Enter a name for the directory in the panel sheet that drops down and click 'Create'.
Goto
Keyboard: ⇧⌘G
So easy. Input a path and go there. Xfile checks the path for validity. Using redundant characters such as '//' in some cases is OK. Paths never end with a forward slash.
Home
A directional command from the default left side of the toolbar. Default is your home area, and with option it's root on your current volume.
Move
Keyboard: ⇧⌘M
An edit command from the default right side of the toolbar. Starts a file-moving procedure. Select a tree node on the left or a number of items from the right and click. A file-moving sheet will drop down. Navigate to your intended destination and click 'Move'.
If you press shift as you click 'Move', Xfile changes to your destination directory on completion.
Movies
A directional command from the default left side of the toolbar. Default is ~/Movies.
Music
A directional command from the default left side of the toolbar. Default is ~/Music.
Pictures
A directional command from the default left side of the toolbar. Default is ~/Pictures.
Preferences
A directional command from the default 'leftish' side of the toolbar. Default is ~/Library/Preferences, with option it's /Library/Preferences.
Refresh
Refreshes the current directory hierarchy and listing. The cool thing here is that this command goes to all open Xfile windows. (Think about that a moment.)
Rename
Keyboard: ⇧⌘N
An edit command from the default right side of the toolbar. Note that for some inadequately explained reasons, 'rename' and Unix 'move' are treated differently. But where Unix 'move' can move a file to another path on the current volume, this 'rename' cannot.
Root
A directional command from the default left side of the toolbar. Default is volume root, and with option it's your home area.
Sites
A directional command from the default left side of the toolbar. Default is ~/Sites.
Terminal
Keyboard: ⇧⌘T
Opens a Terminal.app window (or tab) at the current working directory. (This is very handy, so don't forget to use it.)
Volumes
A directional command from the default left side of the toolbar. Default is /Volumes. This is where the system places temporary mounts.
File → Goto
The full selection of directional commands can be found on the menu at File → Goto.
Symlinks, Hard Links, and More
Xfile also has provisions for creating symlinks and hard links, as well as making it clear as day when you have symlinks and hard links in your listing. Apple will not help you there at all. It's uncertain whether the 'competition' performs better, but it's not worth looking into.
Additional commands can be found on Xfile's File menu.
Caveats
Here's the interesting stuff.
Copy/Move on Apple
Copy/Move on all platforms other than Apple (or NeXT) works the same way. When confronting the Unix underbody to their new OS X system, Maccies had to invent a new word to describe what happens on all other systems: merge. But all systems other than Apple's always 'merge' on a copy or move.
When copying or moving on Apple/NeXT, the first part of the operation must be to remove the destination path if it exists. All Apple/NeXT copy/move ops namely fail if the destination path already exists. Of course this is very dangerous.
If you're running any system other than Apple's, and your destination has 1,000 files but your source has only one file, and if that file's a new file not yet found at the destination, then, after the operation completes, the destination now has 1,001 files.
The Apple/Next way leaves you with one (1) file. It wipes out all the rest.
Why live dangerously as Apple does? Because it's simpler. Even if it risks damage. (The mishaps can be blamed on the user.)
What's involved if you do it the right way? Lots of code and lots lots more testing. Code at this level must reside at the system level and be rigorously tested by the system vendor (Apple) to be exported for general use.
It's important that this code, as with device driver code, is a fundament of any operating system. This code, as with device driver code, must be the responsibility of the operating system vendor and no one else. The operating system vendor. Apple doesn't have that code. NeXT never had it either. Ironically, the one system you should never use online has that code. Microsoft Windows.
On Windows, you have no extensive peek into the innards of the system's file management 'object'. There's one interface. One size fits all. You fill in your 'application form', so to speak, and then submit it, and then at that point the system takes over. The system takes over everything. The system manages user interaction, asks questions when needed, provides progress information, the works. Why? Because this is the dominion of the operating system, not that of a fly-by user-land application.
Inodes
Inode is a made-up word. Because a Unix volume control block is called an ilist. The data in an inode represents all the data the system has on the file. Not shown in the struct are the pointers to the on-disk storage areas. That part is of course managed exclusively by the system.
The inode is a unique index in the ilist, the volume control block. The system uses that index to find the storage for both the data and the metadata. The stat struct represents the metadata. That's where file management comes in.
Inodes are generated automatically by the system. New inodes generally go up, so sorting a listing by inodes will show you which files are oldest, which are most recent.
To access a file, the system first uses the inode to index into the ilist to get the file's metadata (the stat struct etc). Then the system will use the pointers, pointers to pointers, and pointers to pointers to pointers etc to find where the file's data is located on disk.
Unix used a technique known as 'lazy write' for disk I/O, meaning the driver notified the system of the location of its controllers and the system then chose the pending transfer that was closest by. This was done to reduce wear and tear on the media, and this is why veteran admins always ran the sync command twice.
Xfile determines identity by comparing both the file's inode and the volume's device number. Different files on different volumes can in theory have the same inode number - there's a theoretical collision risk.
A Unix file should retain the same inode throughout its life cycle. For obvious reasons. This is however not true on Apple file systems.
The reason dates back several years. The original NeXT code was sound and intelligent, the Apple replacement code is not. What it boils down to is that the 'file save' operation no longer copies in from the temporary storage that's used for safety's sake during an editing session, but moves it in instead. And moving in like this necessitates completely removing the stable on-disk copy. And yes, this does imply a risk for data loss. But, honestly, Apple programmers have never understood file system exigencies.
This further implies that an Xfile refresh with items already selected cannot retain selection for items that have been updated. They should be the same file on any other Unix system, but not here.
Xfile otherwise goes further than any other Mac file manager on the planet. The underlying NeXT technology doesn't offer the logic for this. Whoever designed the frameworks, they chose a very 'purist' approach. So Xfile has to compensate by flagging selections so that they survive a refresh - provided the files, before and after, are still identical.
(No other file manager for the Mac retains selections or scroll offsets on refresh. None. But there's more merriment here - see below, the section about the 'outline view'.)
Selection and focus are two different things. But the underlying NeXT frameworks overlooks this as well. And, as it's not available in the system, it's not available at all. It's namely possible to have focus on a file (commonly a dashed outline) without it being 'selected'. This is seen on most platforms. But not on Apple.
Conveniences
Xfile mode fields are not spelled out as 'read', 'write', and 'execute' They're based on the traditional octal system. Once you learn this system, it's a lot easier. 4 is a read, 2 is a write, and 1 is an execute. Add all three up and you have a 7. It can't be easier than that.
But Apple and others dumb things down even more. They like to instead speak of 'read only'. There is no 'read only' in Unix. There are only three 'rights' to a file, and they are read, write, and execute.
(Unix admits of 'write only', and your system had elements like that - check out ~/Public - but Apple won't help you.)
Brian Kernighan's legendary The UNIX Programming Environment, already in its first chapter, shows you what the execute bit is and why it's so important. You can't even get a shell script to run without it. Yet Apple never offers you the ability to set one. (That's right - and they never explain either. You're just 'SOL'.)
Reading from the right, the three octal digits for mode are for 'other', 'group', and 'user'. Those denominations may been unfamiliar, but those are the terms usually used.
User - that's you.
Group - that's one of the groups you belong to. This can be changed after the fact.
Other - everyone else.
Normally files aren't going to be writeable for 'other'. So watch out. Xscan has a feature for ferreting them out. World-writeable files are understandably considered a security risk. Think about it: anyone anywhere can modify your file? Not good.
Three Levels of Control
It's almost too much. Or already is. But Apple file systems have three levels of control.
The first is of course the one discussed above. For most purposes this is more than enough.
But then there are the 'flags'. There's no formalised name for them - they're just 'flags'.
These flags are sectioned into 'system' and 'user' flags. The entire flags field is a huge hexadecimal number. The MC.app application ('Mode Calculator') can help here.
Finally we have the latecomer, the access control entry. Access control entries are assembled into an access control list for a file. ACL.app can explain and edit them.
Generally it's best to keep things simple. Don't use flags or ACEs unless you really need them. It gets confusing otherwise. And there's no formal definition of which level overrides which level. Currently the flags seem to override all else, with ACEs coming next and 'mode' coming last, but this isn't etched in stone.
The flags and the ACEs can be perturbing. Xscan searches for them if you want. (The 'Filters' menu on Xscan is inspired by the authors of the excellent 'Hacking Exposed' series who once sent along a complimentary copy.)
Files & Blocks
The file size field is in bytes. But this doesn't tell the whole story. Files are stored in (multiples of) blocks. The block is the minimum unit for your secondary storage. Commonly it's a multiple of 512-byte sectors, or 8 or 16 sectors each time. This value can go up quite a lot for other types of storage, such as those found in /dev.
The 'optimal block size' in Xfile, called 'st_blksize' in the stat struct, tells you how much that will be for any given file. Files in /dev, however, can be given an optimal size of 131,072 bytes or 256 ordinary sectors, something that likely can't apply here, but still considerably larger.
Note that directories also consume disk space. Of course they do. Even though other file managers often display 0 (zero) size instead. With an optimal block size of 4096, an empty directory will use only perhaps one hundred bytes or less, 64 being the current number on 64-bit SSH systems - the rest remains unused. But the 4096 is still allocated.
Device Type
You might be curious about the 'device type' field in Xfile ('st_rdev' in the stat struct). Mostly it's just a zero, right?
Scoot over to /dev and try again. Those are 'major' and 'minor' numbers. You can look them up if you're interested.
st_birthtimespec
With st_atimespec, st_ctimespec, and st_mtimespec, you'd think they'd have the good sense to call this one st_btimespec. But no. But this is on the FreeBSD group, not Apple. This is the time the file was created. The st_ctimespec is not a creation time, at least not on FreeBSD.
st_btimespec should be immutable and inviolate but it's not. That one is on Apple.
The Right Model
NeXT came up with the table view and the outline view long before Redmond's finest started tinkering around with souped-up list boxes. NeXT's table view is the equivalent of MSFT's list view, and NeXT's outline view is an outcrop of their table view. Their table view is simply rows and columns of data. Their outline view builds on this by offering hierarchy and a disclosure triangle at the far left of a row.
This is all fine and good for the simplistic universe NeXT was born into in the late 1980s, but it's not close to enough for the complex systems in use today. In addition, the NeXT outline view is a memory glutton. The more that's revealed onscreen, the more RAM that's required. After a while this becomes an unbearable burden.
Xfile saw the way through that by creating a 'hybrid' outline view for its left pane. This view is essentially an outline view with a single navigational column.
Go to your absolute file system root with Xfile and 'expand all'. This will take time - there are hundreds of thousands of folders in your system - but you'll get there.
You won't get there with any other file manager for the Mac.
Steve Gehrman's Path Finder is aware of this weakness, and holds onto an internal 'counter' so no single node will be expanded too many times. For Steve knows what happens otherwise - it happens to Apple's Finder.
Placed in the same predicament, Apple's Finder will either hang or crash, whichever comes first.
Xfile avoids all that by choosing the right model. A model that, in addition, is frugal with your system resources.
Click a folder on the left, and memory allocated for the directory on the right is freed before moving on to the new location. There is no allocation buildup as with Finder or Path Finder.
Open (File With Application)
Keyboard: ⌘↩
This comes from NeXT and it's very welcome: a low-level API for opening documents and launching programs.
Full details are available in the Xfile documentation, but briefly:
- To launch a Cocoa application, select it and invoke the Open command. The first field shows the path to the application; the second field is blank. Just hit Return.
- To open a directory bundle such as a NIB bundle or an Xcode bundle, do the same: select it and invoke the Open command. Just hit Return.
- To open a document with its default viewer, select it and invoke the Open command. The full path to the default viewer will appear in the bottom field. Just hit Return.
- To open a document with other than its default viewer, select it and invoke the Open command. The full path to the default viewer will appear in the bottom field. Overwrite the name of the viewer with the name of the viewer to be used in its stead. The full path need not be given and the 'app' file extension can be omitted. Just hit Return.
- To run a Cocoa application, invoke the Open command, clear both fields and enter the name of the application in the bottom field. The full path need not be given and the 'app' file extension can be omitted. Just hit Return.
Doug McIlroy famously warned about this 'Mac' way of thinking. Action-oriented (as opposed to document-oriented) platforms completely circumvent this. But people, seriously, need to be able to view and edit any file with any program. Apple may have this embedded 'way down there', but this puts the interface right up there when you want it.
The interface is found in a number of ACP file management utilities, such as Xfile. GDE, Tracker, Xfind, Xscan, and Xshelf. It's also found in the standalone Runner.
Intuitive
Xfile is meant to be intuitive. If you think something might work, try it. You can drop both files and directories on the Xfile 'non-client' area - the toolbar area and above.
Xfile acts as both a drag-drop client and server, but only as a client with itself and other ACP file management utilities. Xfile can't be responsible for what other utilities do.
Don't Trust Apple
Finite file transfers are OK, but enterprise-wide operations should be done at a Terminal command line. Make sure you never move across volume boundaries. If you want to move serious data, remember Tom Karpik.
When 'moving' serious data over volume boundaries:
- Drop down to a command line.
- USE ONLY COPY, NO MATTER WHAT.
- Patiently wait, then verify with FileMerge or Rixcomp.
- Don't delete the source until you verify.
It's that simple
File management should be simple. A file manager should be robust - it's the most important utility in your system.
File management code should be single-threaded. As one of IBM's OS/2 engineers in Boca Raton once put it, multithreading is a Pandora's Box. If other threads get involved, let it be the system that does it, not your file manager.
A file manager is the 'pretty face' to the system's file management logic, just as a web browser is the 'pretty face' to the system's web navigation logic. You don't go inventing your own parallel file management subsystem. If the system you're on doesn't have an adequate file management module, then migrate to a better platform.
Apple's system is close to the line. Vanilla Unix systems (FreeBSD, Linux) are better in that respect, but they use the paraplegic Windows interface model (probably on purpose, sadly). And way back when Apple just inherited NeXT, no one knew how things would turn out.
If you're going to be on an Apple system, then Xfile is the only way to go. Xfile is not a bunch of bloat and tangled wires. Peek under the bonnet and see for yourself. No one else comes close and you know it.
How To Get It
How to get it? You can get it for free, or you can pay.
The Test Drive
The ACP Test Drive is not shareware. It's freeware. We do not put booby traps in purchased software or any software. We never have and we never will.
Information about the free ACP Test Drive can be found here:
https://rixstep.com/td
That's a free test. No strings. Some features found in the purchased version are not available in this version, but this should give you a good idea how things work. There are no time constraints. In fact, this may be all you need.
The Full Version
The full version of Xfile and all the ACP utilities comes bundled as one package. They're designed to work together.
You can find the details here.
https://rixstep.com/acp
The price may seem steep, but it's discounted for now, and it's a one-time fee. We used to have a 'subscription renewal' system, but we dispensed with that. Once you're in, you're in. You keep getting free updates for life.
Xfile is part of the ACP, and the ACP is a package of utilities. We can keep updating those utilities, we can keep adding new utilities, but it costs you nothing.
The ACP Test Drive has a dozen utilities, but the full ACP has over seventy. And then there are gobs more command-line tools and stuff, bringing the total number of titles up to over 120. So take a look.
About RixstepStockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.
All Content and Software Copyright © Rixstep. All Rights Reserved.
|