Last week I drew attention to problems interpreting the timestamps of files in macOS, generating lively discussion with Chris and Richard. Although the gist of that article stands, it was clear that there remained several issues, and this sequel tries to address those better, with the aid of a new app, Dropera 2. The TL;DR for this article is that timestamps are even more complicated than I previously described.

The first task was to develop a tool for reading and recording these timestamps reproducibly. Although the four key timestamps are exposed in Precize, opening a file in that app is likely to change at least one of them. For a substitute I turned to an earlier SwiftUI demo, Dropera, with its drag-and-drop support to handle file URLs without opening, reading or otherwise changing the file.

Timestamps

This new version of Dropera had then to read the right timestamps and convert them into accessible dates and times. For some timestamps, we’re spoiled for choice: time of creation of a file, shown in the Finder as Date Created, is saved in an APFS file’s attributes as create_time, exposed in the stat command as st_birthtime, and accessible within an app’s code as the NSFileCreationDate file attribute or creationDate URL resource. To establish which timestamp is which, I have compiled a table giving the sources I have been able to discover.

For Dropera, following careful comparison with the values delivered in stat, I selected:

• Creation from NSFileCreationDate
• Modification from NSFileModificationDate
• Attribute modification from attributeModificationDate
• Access from contentAccessDate.

The last two aren’t available in the Finder or elsewhere in the GUI, while the Finder does provide Date Last Opened, Date Added and Content Created:

• Date Last Opened isn’t related to Access Time, but is recorded in the com.apple.useddate extended attribute. Unfortunately, adding and manipulating that may change the Attribute Modification timestamp, so has to be avoided. As Apple doesn’t appear to document the xattr or its interpretation, I have avoided looking at it any further here.
• Date Added is the timestamp when a file was added to its current directory. As that isn’t strictly speaking a file attribute, I will ignore it here.
• Embedded records of Content Created require file data to be read, so accessing them is likely to update at least one of the key timestamps.

Each of those three is available from the metadata indexed by Spotlight, but that’s an indirect and unreliable way to access them.

Using Dropera

To use Dropera to read the four key timestamps just drop the file onto its window, and the app will then display the filename, its path, and the four timestamps in the order of Creation, Modification, Attribute modification and Access times.

Adjust the window width to make these most convenient to read. The layout shown above is compact and automatically splits each timestamp into date and time components. In other uses, you might prefer to widen the window so each entry takes a single line.

To refresh the values shown for the current files, click on the Refresh tool. Although the window continues to display just the single set of entries, the previous timestamps are saved in memory, and the whole history since the last drag-and-drop onto that window can be exported to a text file using the Save as text tool. You can also select the line of results, copy and paste that into another app if you prefer.

Drop multiple files onto Dropera’s window and all their timestamps will be shown. You can then select continuously (Shift-click) or discontinuously (Command-click) to copy those values, and Refresh them.

Demonstration

Open TextEdit, create a new file and set its type to plain text. Add a few words and save it somewhere convenient. Then open Dropera, and drop that file onto its window to inspect its timestamps. They’re likely to show Creation and Modification times the same, Attribute modification slightly later, and Access another second or so afterwards.

Next make a small change to that document and save it. Click Dropera’s Refresh tool and only the Creation time remains unchanged. Close that document in TextEdit, and Refresh the times again to confirm that none have changed. Now select the file in the Finder so its QuickLook thumbnail is previewed. When you Refresh its times, you should see its Access time has been updated. Now double-click the file to open it in TextEdit, and check times again while the file is still open. Attribute modification and Access times are altered, but remain the same after you have closed the document. Export those records as a text file, and you should see:

• Creation time remains unchanged throughout.
• Modification time changes once, when the second version was saved.
• Attribute modification time changes twice, when the modified file was saved, and when the file was reopened.
• Access time changes three times, the additional occasion being when you viewed the document’s thumbnail in the Finder.

Dropera 2, which requires macOS 14.6 or later, is available from here: dropera20

Enjoy!

If you ever encounter an error when checking an APFS volume using First Aid in Disk Utility or fsck_apfs, you won’t be informed of the path and name of the item responsible, but given its inode number, in an entry like
warning: inode (id 402194151): Resource Fork xattr is missing for compressed file

The inode number given can only be resolved to a path and file/folder name if you also have a second number giving the volume for that item. As that will be for the volume being checked at the time, you should be able to identify that immediately. The only time that you might struggle to do that is with items in a snapshot; those should, I think, be the same as the volume they are taken from. However, as snapshots are read-only, there’s probably little point in pursuing errors in them.

To resolve these in my free utility Mints, open its inode Resolver using the Window / Data… / Inode menu command. Drag and drop another file from the same volume onto that window.

The Resolver will then display that file’s volfs path, such as
/.vol/16777242/1241014

All you need do now is paste the inode number given in the warning or error message in Disk Utility or fsck_apfs, into the Inode Number box at the top of the Resolver window, and click the Resolve button. Mints then looks up information for that inode number on the same volume, using GetFileInfo, and displays it below.

One drag and drop, a paste, and a click to discover what APFS is complaining about.

Command line

You’ll sometimes see Terminal’s find command with the option -inum recommended as a way to convert from an inode number to a regular path. Although you can do that, it’s easier to use the command GetFileInfo instead. For that you’ll need the full volfs path, including the volume number.

To find the volume number, use my free utility Precize, and open another file on the same volume. The second line in its window gives the full volfs path for that file. Copy the start of that, leaving the second number, the inode, such as
/.vol/16777238/

Alternatively, you can use the stat command as given below.

In Terminal, type
GetFileInfo
with a space at the end, and paste the text you copied from Precize. Then copy and paste the inode number given in the First Aid warning, to assemble the whole command, such as
GetFileInfo /.vol/16777238/402194151

Press Return, and after a few seconds, you should see something like
file: "/Users/hoakley/Library/Mobile Documents/com~apple~CloudDocs/backup1/0MintsSpotlightTest4syzFiles/SpotTestA.rtf"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 05/17/2023 08:45:00
modified: 05/17/2023 08:45:00
giving the full path and filename that you want.

GetFileInfo is one of the oldest commands in macOS, and has been deprecated as long as anyone can remember. I suspect that Apple is still trying to work out what can substitute for it.

Get a volfs path for a file

Use Precize to run this the other way around: open the file and read the path in that second line. To copy the whole of it, press Command-2.

The simplest ways of obtaining inode numbers 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 number 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 number, and the second is the inode number of that item, or /.vol/16777220/36849933.