|Home » Learning Curve » ACP Guru
Managing File Attributes Revisited
A look at all the things your Finder doesn't give you. Updated for 2019.
[an error occurred while processing this directive]
File system attributes are half of your system security. The other half is your kernel which cooperates so well and dutifully with file system attributes. On a secure system all file operations have to pass from the user through an application, down to the file system APIs, through to the kernel, and from there to the file system drivers.
No one is allowed to disrupt the chain of command.
Taking a peek at your file system with your Finder isn't going to tell you squat. The Finder today is little more than a fancy image browser. It 'finds' files alright (at least in sometimes - ouch) but it doesn't really do much with them.
Comparing what the Finder does with what can and should be done is pointless - the Finder doesn't do much at all. The better place to start is with simply showing what's available and what should be at your beck and call.
Standard Unix File Permissions
Unix files have something called a mode. This modes includes file permissions. File permissions are divided into three groups: for the file's owner, for the owner's group, and for everyone else ('other'). Each group has three attributes for reading, writing and executing.
File permissions are commonly expressed either as an octal number or as a sequence of alphabetic characters. The following two illustrations shed a bit of light on what's going on.
The first image is what Xattrib shows you. It spells out the attributes a bit more than often seen.
|File Type||The 'real file type' according to Unix. This isn't something you can alter. Dock.app's executable is a 'regular file' - an 'ordinary file'.|
|'Extra Bits'||These are the sticky bits and the set ID bits. There are three: Sticky Bit, Set GID, and Set UID. More on them later.|
|Access||Read, Write, Execute bits divided up for User, Group, and Other.|
|User Flags||Extended flags that override ordinary file permissions.|
|System Flags||Extended flags that override all other file permissions.|
The second image is what the ACP Framework shows you in applications such as Xfile, Xscan, Xfind, Tracker, and others. It spells out more than the attributes.
|Device||The ID of the physical device the file resides on.|
|Device Type||This will be '0' unless the target is a 'device file' in /dev.|
|Inode||The volume control block index for the file's information.|
|Size||The size of the file in bytes.|
|Mode||The file's mode displayed in octal. Note this includes more than ordinary permissions.|
|Blocks||Implies the full storage requirements of the file. A 'block' is normally 512 bytes.|
|Links||The number of (hard) links to a file. A physical Unix file can be referenced by any number of file system paths.|
|Optimal Block Size||This is the optimal size for I/O. Normally 4 KB (4096 bytes). This becomes the basic I/O unit used by the file system drivers.|
|Owner||Self-explanatory. This is the 'user' - the account that created the file. Only the root account can change the ownership of a file.|
|System/User Flags||These are the extended flags (displayed in hexadecimal) that override (veto) ordinary file permissions.|
|Group||The group the file belongs to. The file's owner can in some circumstances change this field.|
|File Generation #||Only visible to the root account. Not found universally on Unix. Beyond the scope of this article.|
The mode is shown in octal in the second image; at the command line this is often shown in a string format.
$ ls -@ilO Dock
4319131187 -rwxr-xr-x 1 root wheel - 5468560 May 1 14:15 Dock
The '-rwxr-xr-x' corresponds to the '0755' from the second image above and to the 'Access' section of the first image. All the remaining fields correspond to further data seen in both the above images.
|4319131187||The file's inode, essentially an index into the volume control block.|
| - ||This extra character on the far left denotes the file type. Regular files get a hyphen; directories get a 'd'; and so forth.|
| rwx ||Denotes the rights for 'user' - the file's owner. Dock.app's executable can be read, written to, or executed by its owner.|
| r-x ||Denotes the rights for the file's group. Dock.app's executable can be read and executed (but not written to) by members of the group 'wheel'.|
| r-x ||Denotes the rights for 'other' - everyone else. Dock.app's executable can be read and executed (but not written to) by anyone.|
| 1 ||The number of links to this file. There is but one - meaning there is no other path that refers to the same physical file.|
| root ||The file's owner.|
| wheel ||The group the file belongs to.|
| - ||A placeholder for extended flags. The hyphen means there aren't any.|
| 5468560 ||The size of the file in bytes.|
| May 1 14:15 ||The 'last modified' time of the file.|
| Dock ||The name of the file.|
'Octal' is but one way of expressing bit values but it's the one traditionally used for Unix file modes and it's the most convenient as well. Unix file modes - including 'permissions' - are expressed as six octal digits.
Dock's full file mode field is '100755'.
| 10 ||These leftmost two digits denote the file type. The file type of Dock is '10' - 'regular file'.|
| 0 ||This single digit holds the sticky bit and the set ID bits. Dock has none.|
| 755 ||The actual file permissions.|
Octal file permissions are easy to read (and ultimately easier to work with) in octal - they're bit-wise.
| 4 ||Read.|
| 2 ||Write.|
| 1 ||Execute.|
The '7' in Dock's permissions means the owner can read (4) write (2) and execute(1). But group and other don't have that '2' - they can't write to the file.
Following are the values for Unix file types. Dock's file type field is '10' - and yes it's very much a 'regular file'.
| 01 ||FIFO or named pipe|
| 02 ||Character device|
| 04 ||Directory|
| 06 ||Block device|
| 10 ||Regular file|
| 12 ||Symlink|
| 14 ||Socket|
| 16 ||Whiteout|
Extended attributes - or XAs - were new to OS X starting with version 10.4 Tiger. They supersede and add to the old 'Finder file and folder info' and 'resource fork' cruft left from the 'beige box days'. They have an open 'Unix' style API and potentially free OS X from its limitations in communicating with other platforms.
Theoretically anything can be stored with a file as an extended attribute but two attribute names are reserved and require conformance with other standards.
|com.apple.FinderInfo||Used to store the classic file and folder info. This data must be exactly 32 bytes in size.|
|com.apple.ResourceFork||Used to store the classic resource fork info. This data must conform to resource fork constraints.|
All other extended attributes are arbitrary and can be named and can store data on an arbitrary basis. The ACP applications Clipothèque and Xbase are two Rixstep applications which use this technology extensively. Following is what shows up in the ACP application Xattr when a Clipothèque file is dropped on its Dock icon.
Selecting 'Display Text' reveals that the data is a property list in binary format.
There is one extended attribute stored with this Clipothèque file; its name is 'com.rixstep.Clipotheque' which follows the recommended name standard; and Xattr can export it so other applications can inspect its contents.
The XA can be viewed in PlistEdit as plain text.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<string>896 178 368 343</string>
So that's it - the XA contains (file-specific) window frame coordinates, column sorting information, and column widths. All Clipothèque (and Xbase) windows come back exactly as you left them. These extended attributes can be used for anything anyone wants. Several applications can store their own attributes with any one given file - there might be a particular way a text editor or a property list editor wants to remember a file's 'spatiality'. There are no limits; there is no sky.
Xattr: No More Oompas
Xattrib: Fathoming Unix
Stockholm/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.