About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Learning Curve

On File Management (5)

Part five.

Buy It

Try It

Xfile addresses most of the issues seen in the previous articles in this series.

  • .DS_Store gone. Unless of course you use 'TFF'.
  • Spatiality isn't an issue. Xfile is a file manager, not a 'creator of folders'.
  • No file type conflicts. You can't destroy a folder and thousands of files with a single file.
  • All file data exposed. Not 'metadata' but actual file system data. All is editable as well.
  • Control of sticky/set ID bits. You see why things are acting strangely and correct them.
  • Full control of permission bits. You can set more than 'read & write'.
  • Hard links, extended attributes, access control entries. All modifiable when possible.

Finder doesn't show you more than a fraction of your file system. 'Finder replacements' weighing in the 100 MB range are buggy and take eons to load and do anything. Professionals need a tool that works fast, gets in and out before other programs have the time to load, and is intelligent, robust, and reliable.

The red thread through Xfile design is that the program - with few exceptions - concentrates on what is generic for Unix file systems. Add-ons or Apple idiosyncrasies can come and go, but the instrinsic nature of a Unix file system will remain.

Other applications related to Xfile do other jobs outside Xfile's strictly defined area - things like searching directories, searching within files, manipulating non-standard extended attributes, manipulating legacy (archaic) 'Mac OS' info, going even lower into on-board disk logic, and so forth.

Xfile and the related applications - and you the user - benefit by this because code is kept modular, because there's less chance for bloat and bugs, because the individual applications can be maintained sensibly without risking a collapse in the 'house of cards' often seen in other file managers.

Xfile is designed so it works in all possible situations, all possible constellations. There are no specific file operations that can render it inoperable - as has been seen with both Finder and the 'Finder replacements'.

Ten Columns

Xfile displays ten columns of data in its right pane.

√ Name - no quibbling there. A name is a name is a name.

√ Size - this can actually be many things. It might be only one thing on standard Unix/Linux systems but on OS X it's many. Earlier 'resource forks' are now handled as 'extended attributes'; a field known as 'Finder info' (and presumably held in the VCB separately) is also an extended attribute under the current regime. Applications can now add their own arbitrary attributes and a number of ACP applications take advantage of this to provide true document-based settings where the system is otherwise not capable of this.

Thus the file size can be more than the file size. The base size is the actual data; to this is added the combined sizes of all of the extended attributes. Files with extended attributes are signaled by rendering in an alternate colour.

√ Inode - an important field as it's one half of the actual identifier of a physical file. A file name can change without the file itself being affected. This field is categorically ignored by 'TFF' and most replacements yet it remains a critical part of the only method of establishing identity.

√ Links - this correlates to the number of links to a physical file. A link is a reference in a directory (file name) to an inode (which in turn, aside from being the file's sole unique identifier on the volume, serves as an index into the volume's volume control block - ilist in Unix parlance).

As the reference to a physical file (file name in a directory) is totally separate from the physical file itself, it stands to reason that any file can have multiple references - multiple 'links'. Directories will always have a link count greater than one; on OS X this is close to the HFS concept of 'valence' - the number of directory entries for the directory in question. The link count is the number of actual references (path + file name) for the file. Links above and beyond the first such link are commonly known as 'hard links' - they all point to the same physical file. Any change to the file through accessing one link will naturally result in the file being changed through the other links as well, as there is but one single location for the file on the volume.

√ Owner - all Unix files have an owner. (Thank goodness for that.) The owner of a file you yourself create is mostly going to be the user account you logged in with. It is possible to change this field, whereby knowledge of file ownership becomes very important. File permissions are in terms of owner, group, and everyone else, so ownership plays an additional role here.

√ Group - all Unix files are assigned a group. The group ID together with the file permissions determines access rights for users who are not the file's owner but still belong to the file's group.

√ Accessed - Unix file systems keep track of when items (directories, files, et al) are last accessed. This is done down at file system driver level but it's also programmable. See the documentation for Tracker for a glimpse into what this means.

√ Changed - the time stamp for changes in the file's status information. All file status information is kept separate from the file itself and even the directory in which the file is 'located'. (Directories contain only a file name and an inode - nothing else. All else is in the ilist.) This field gets bumped whenever anything in the iblock for the file is altered - anything at all. This field cannot be modified programmatically.

√ Created - the time stamp for the creation of the file. This field is programmable and exists only on OS X 10.6 or higher.

√ Modified - when the contents of the file were last modified.

√ Mode - or actually part of it. The Unix mode field is represented best as six octal digits whereof the two leftmost cannot be altered as they're the 'Unix file type'. Unix file types are as follows.

Character device
Block device
Named pipe/FIFO buffer
Regular file
Symbolic link

A few words about some of these file types.

Block and character devices are generated for the directory /dev at boot time (and not seen with any file manager other than Xfile). Block devices do I/O by 'block' (data chunks) whilst character devices stream a byte at a time.

Symbolic links are files that contain only a path to another file. So that in ordinary circumstances, attempting to access a symbolic link (or symlink for short) will actually access the dereference instead. (Xfile is however capable of accessing the symlink itself.)

The third digit from the left has some 'extra bits' in it - bits that are extremely important for file management, bits that are never shown in the Finder or in most Finder replacements. The value of this digit is a combination of three values.

1 - 'sticky bit'
2 - 'set GID'
4 - 'set UID'

The sticky bit, used originally to single out process files that should not be swapped out of memory, is used today on directories to give them special characteristics. A directory with a sticky bit might let you save files in it but won't let you remove them unless you're the owner.

Both the 'set GID' bit and the 'set UID' bit are used for privilege escalation - when being just you isn't good enough and someone wants to help you be someone else. A program file with the 'set GID' bit will let you assume the privileges of the file's group if you're at all able to run it; a file with the 'set UID' bit set will let you assume the privileges of the file's owner if you're at all able to run it.

Needless to say, these bits are both powerful and dangerous. And you need to both check for the existence of such bits at all times, add them if you feel the need, and remove them if you find them questionable. The Finder offers you absolutely nothing in this regard. In addition to all its other features, Rixstep's Xscan performs thorough security checks that find all such files in your system.

The final three digits in the file's mode field are the actual permission bits (whereby it's incorrect to do as some 'file managers' do and call the field a 'permissions' field - it's only three of the six digits that have to do with permissions; the others are those already explained above). Seen from the left, the digits are for the permissions of 'user', 'group', and 'other'.

'User' is the file owner; 'group' is the file's group; and 'other' is for everyone else. The value of each of these three digits is a combination of three values.

1 - eXecute
2 - Read
4 - Write

'Execute' comes into play for programs, scripts, and directories. In the first two cases the connotation is obvious: you need to have 'execute' permissions to run a program or a script. In the case of directories, you need to have this bit set in order to set your 'current working directory' (CWD) within.

'Read' means what it sounds like - you need this bit to read any sort of file (including directories - without this bit you can't list the contents of a directory).

'Write' means what it sounds like too - you need this bit to write to any sort of file (again including directories).

Fully understanding how the 'write' bit affects directories requires being reminded of what's actually contained in directories: arrays of file name/inode pairs. To do anything with the contents of a directory, you need the 'write' bit for the directory.

So renaming a file doesn't require special permissions on the file - it requires the 'write' bit for the file's directory. And doing something as innocent as adding a file to a directory requires the same thing. As does removing a file (or moving it to another directory). In all cases, the directory (just another file actually) has to be written to; without the 'write' bit, this is not possible.

The ACP framework inspector sheet offers the remaining status fields - device number; device type (used in /dev, otherwise 0); number of (512 byte) blocks; optimal block (I/O) size (which can vary depending on file type of course); and file generation number. These are fields that can't be edited - they're not germane to file management - but can be important to review from time to time.

The inspector sheet also deferences symbolic links, shows full file names, parent directories - all data in the file's iblock.

It's important that all of the above information be available. Some 'file managers' that 'come and go' offer 'some' but not all information on the rationale that 'but most people don't need to know this or that'. Which of course is preposterous. And real programmers, admins, and even power users want - need - to see it all. If your file manager can't show it to you and let you manipulate it, who or what will?

Not that this doesn't have to be tempered with practicality. A test version of Xfile exposed the file flags as a separate column. But all that led to was a column of eight zeros per line all the way down the window. File flags are used so seldom; they can be manipulated through the inspector; and today the mode field is rendered in an alternate colour to indicate something may be going on with the file flags.

See Also
Learning Curve: On File Management (1)
Learning Curve: On File Management (2)
Learning Curve: On File Management (3)
Learning Curve: On File Management (4)

Developers Workshop: It Wasn't Good Then, It's No Better Now

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.