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

Home » Learning Curve » ACP Guru

Managing File Attributes

A look at all the things your Finder doesn't know how to show you.

Get It

Try It

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 the 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 some of the cases) 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 'mode' includes file permissions but file permissions don't include the mode. Unix file permissions are divided into three groups for the file owner, for the group owner, and for everyone else. Each group can have up to 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.

$ pwd
/System/Library/CoreServices/Dock.app/Contents/MacOS
$ ls -@ilO Dock
2074433 -rwxr-xr-x  1 root  wheel  - 2384736 Sep 25  2008 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.

-	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.
2384736	The size of the file in bytes.
Sep 25 2008	The 'last modified' time of the file.
Dock	The name of the file.

Six Digits

'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

Extended attributes - XAs - are 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.

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.

This XA happens to be a property list in binary format (very appropriate) and so can be opened by 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">
<plist version="1.0">
<dict>
    <key>Frame</key>
    <string>896 178 368 343</string>
    <key>Sign</key>
    <integer>1</integer>
    <key>Sort</key>
    <integer>0</integer>
    <key>Widths</key>
    <array>
        <real>350</real>
        <real>10</real>
        <real>10</real>
    </array>
</dict>
</plist>

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.