In my previous article, I looked at some of the more recent changes which have happened to the way that data is stored in files, including sparse files, clones and compression. This article moves on to the next components of a file, its attributes – the file’s name, dates of creation and modification, and more.

A file’s attributes are metadata in categories which are common to all or most files, many being required. Although I’m sure that some file systems allow certain files to have no name at all, one of the standard requirements for APFS is that each file has a name which is distinct within that directory, and it won’t allow two files in the same directory to have what it considers to be the same name.

inode

The most fundamental attribute of any file, at least on local storage, is its inode, a number which is unique within that file system (volume). This enables every file (and directory) to be uniquely identified by its inode coupled with the number assigned to that volume. Inodes are used in two related but different file systems which can be used to specify files on APFS, HFS+, and other file systems which can be understood by macOS: the volfs path, and the File Reference URL.

For example, I have a file at the path /Volumes/External1/Documents/0newDownloads/2020anniversaries.txt, which the Finder displays when I open the 0newDownloads folder on my external SSD named External1. That has an inode of 1841195 on the volume numbered 16777260, so its volfs path is given as /.vol/16777260/1841195. The File Reference URL uses a different volume number with the same inode, and works out as file:///.file/id=7085865.1841195. Although these aren’t the way you and I would normally want to refer to that file, they’re more precise, and survive changing the file name and changing the names of intermediate folders and volumes. As the inode is the internal file system reference to that file, it’s important when you need to look at files precisely. APFS stores the inode of each file system object in its record header, in j_inode_key_t/j_key_t.

The simplest ways of obtaining inodes and so building volfs paths in Terminal are using the -i option to the ls command, and for individual items using stat:
ls -i lists each item in the current directory, giving its inode first, e.g.
22084095 00swift
13679656 Microsoft User Data
22075835 Wolfram Mathematica
and so on;
stat myfile.text returns
16777220 36849933 -rw-r--r-- 1 hoakley staff […] myfile.text
where the first number is the volume inode, and the second is the inode of that item, or /.vol/16777220/36849933

My free Precize gives both the volfs path and File Reference URL without any effort.

Associated with the inode is that item’s reference count, the number of file system entities which refer to that item. This is important for the file system, so that it knows when that item is no longer referenced and can be removed. For example, if a total of three items link to a single file, using hard links (symbolic links and Finder aliases don’t count), then the file can’t be deleted until all three of those items have been deleted.

Name

File names are a complex area, with particular reference to case sensitivity and Unicode normalization. Historically, HFS+ has normally been case-insensitive but case-preserving, and performs Unicode normalisation. This means that it won’t let you have two files in the same folder whose names differ only in their case. Unicode normalisation ensures that many accented and other characters which look the same in Unicode are treated as if they are the same, by mapping those characters to common ones – a complex subject which is even worse when it comes to some languages such as Korean.

Originally, APFS was intended to ignore those standards altogether, and just treat file names as a series of bytes. So long as two names differed somewhere, then those items could have existed in the same folder. There were serious problems with that approach, because many Mac apps and their users were used to the conventions of HFS+. In the end, Apple relented and the standard variant of APFS used for macOS behaves similarly to HFS+ – it’s case-insensitive but preserves case, and performs Unicode normalisation. That isn’t true for iOS, though, which uses the case-sensitive variant of APFS, an option which normally wreaks havoc if used on a Mac.

Dates

macOS and APFS (like HFS+) are particularly rich in attributes, supporting not only standard timestamps for the creation of files and other items, and for the latest date of their modification, but others such as the date the attributes were last modified.

Interpreting these can sometimes get complex. When you change the data within a file, in its ‘data fork’, its date of last modification is also altered. But making some other changes to that file won’t alter its date of last modification. Changing the file’s permissions or other attributes should change its attribute modification date, but not date of last modification. Changing its extended attributes is also not reflected in any change to its date of last modification.

These become significant for apps which rely on changed dates, for example to determine whether to make a backup of that file.

Unix/Posix permissions

At their most basic, these assign an owner, a group, and general permissions, in terms of whether an item can be read, written to, or is executable. They’re expressed in different ways too, according to where you look: in the Finder’s Get Info dialog, they’re shown with names associated for owner and group, in terms of verbal privileges for each. When listed in Terminal, they may appear as a pattern of letters such -rw-r--r-- but are commonly specified in octal (base 8 digits), such as 600, and associated not with owner or group names but their numbers, e.g. 501 for the primary admin user.

UTI

Every item in a Mac file system should also have an associated type, given normally as a UTI such as public.plain-text for a plain text file. This tells systems such as LaunchServices what it should do when you try to open that item. UTIs are now determined largely by other attributes, such as whether the item is a folder/directory, and for files by their filename extension.

Specialised attributes

External file systems such as those used by cloud services require additional attributes in order to manage files stored there. For example, macOS has a set of Ubiquitous Attributes for iCloud, including whether the item has been uploaded or is uploading at present, whether it had been downloaded or download has been requested. The most fundamental of these is the attribute isUbiquitousItem, which indicates that the item is in iCloud.

There are other attributes, and many of the most important are displayed using Precize, which also lists Extended Attributes, the subject of the next articles in this series.