Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

On File Management (6)

Part six. Left pane/right pane. No tapping.

Get It

Try It

An Xfile window has two 'panes': one on the left; and one on the right. The pane on the left is a hierarchical structure of the file system directories ('folders' to the Unix neophyte). Common OS X file systems have in excess of 20,000 directories. The left pane is a drag client only.

A hierarchical structure with countless nodes for in excess of 20,000 directories requires a considerable 'data source' to back it up - this even if all that's being 'sourced' are the directories themselves. For each node has a name as well as a structure for the child directories, each of which is of the same data type as the parent itself, each one capable of holding additional structures for each of its 'children' ('grandchildren' of the original parent). 20,000 structures - or code classes - kept in a strict hierarchical relationship needs considerable memory resources without going into the further contents of directories. The Xfile directory structure shows only directories - not files contained in those directories.

Selecting a directory in the hierarchy on the left automatically lists the contents of the selected directory on the right. Some directories contain only the two perfunctory entries '.' and '..' (and some don't contain even those). Some directories on OS X contain quite a bit more. The current 'record holder' on OS X - /usr/share/man/man3 - contains nearly 9,000 entries. That's quite a lot of files. (The directory is used by the Unix 'manpage' system.)

The pane on the left has to be able to tell the OS X (Cocoa) callback layer whether directories in fact have 'children' (they get a 'flippy triangle') and in such case the number of children. This is used by the Cocoa callback layer to calculate displacement for rendering things on screen.

The pane on the right is designed to store all practical data on directory entries - a lot more than any other file manager for the platform. This is necessary because a file manager has to be agnostic in its presumptions of what a user needs. There are a few exceptions (such as when a data field is rarely used) but most of the data fields have to be included. Xfile has a total of ten data fields rendered in the right pane for any given file. Again: this is both a necessity and also a lot more than any other 'file manager' for the platform dares deal with.

As explained in a previous article in the series, the data fields are name, size, inode, links, owner, group, accessed time, changed time, modified time, and mode. The created time field, new for OS X 10.6, is not included for purposes of consistency with earlier versions of OS X and for reasons of irrelevance (but is included in the 10.6 ACP framework inspector).

Ten fields are sufficient for describing the status of any file in OS X - and the exceptions endemic to Apple's implementation of the generic Unix file system are dealt with in an appropriate manner.

It's important for the sake of accenting the 'Unix' in OS X to keep abnormalities out of the ordinary data stream and deal with them in another separate way. These 'abnormalities' namely come and go: Xfile, being a Unix file manager, does not have to be re-factored for such changes. Stability wins.

OS X files can have 'extended attributes' attached to them which then increase their total disk space requirements. Files with extended attributes have their size fields indicate this but also render the size field in an alternate colour in Xfile to signal the user that something out of the ordinary is attached to the file.

OS X files and directories can also have 'file flags' and 'access control entries' attached which further affect permissions as otherwise given in the mode field. The mode field isn't affected, but Xfile signals the user again by rendering the field in an alternate colour. Inspection of the file's status with the inspector sheet will in such case reveal the presence of special flags; use of the ACP ACL.app utility will otherwise reveal the presence of access control entries.