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!

Timestamps on files and folders are important, and can be used for many different purposes, from sorting files to find the most recent, to providing evidence in court. Each file (and directory) in APFS has four separate timestamps you can use:

• Created, termed in APFS create_time, gives “the time that this record was created”.
• Modified, mod_time, “the time that this record was last modified”.
• Last opened, access_time, “the time that this record was last accessed”.
• Attributes Modified, change_time, “the time that this record’s attributes were last modified”.

Although the Finder only displays those to the nearest second, the macOS API readily provides fractions of a second, commonly resolved to milliseconds, and the raw values are saved as nanoseconds since 00:00 UTC on 1 January 1970.

The first three are those most commonly used, although the last can be relevant in backups in particular. If you want to see which file in a folder is the oldest there, look for the oldest time Created. If you want to know which was most recently changed, look for the latest Modified time.

Where you must be careful is in interpreting those dates, as it’s easy to make assumptions that may not always work. The first confounding factor is that files can change without updating the Last opened time.

Apple’s APFS reference states that access_time is updated according to the behaviour set by that volume’s APFS_FEATURE_STRICTATIME setting. “If this flag is set, the access_time field of j_inode_val_t is updated every time the file is read. Otherwise, that field is updated when the file is read, but only if its value is prior to the timestamp stored in the mod_time field.”

Does APFS in macOS currently set the APFS_FEATURE_STRICTATIME for its volumes?

You can see how that works in a simple demonstration. Create a new text file in TextEdit and add a line or two of text to it, then save it. In the Finder, Created, Modified and Last opened timestamps will now all give the same time and date. Leaving that file open in TextEdit, wait a couple of minutes, then add another line to the file and save it again. In the Finder, the Modified time will be updated, but not the Last opened time, because the file hasn’t been opened and read again. Close the file, wait another couple of minutes, and open it again. You should see its Last opened time update, indicating that APFS_FEATURE_STRICTATIME is set for that volume.

My example is even more extreme. According to these timestamps, this file was Created on 13 July, and hasn’t been opened since. However, it was modified without being read on 23 September. If it’s opened and read now, it’s Last opened time will be updated whatever the APFS_FEATURE_STRICTATIME setting.

There’s another confounding factor that makes this even less reliable: QuickLook. Although its thumbnails and previews are constructed using file data, that access doesn’t affect either the Modified or Last opened timestamps, and opening and reading a QuickLook Preview isn’t recorded anywhere in a document’s attributes. So it could be extremely misleading to assume that a file hasn’t been viewed just because its Last opened timestamp hasn’t changed.

If you do want to use the timestamps on files or folders, it’s essential to know their limitations and behaviours, otherwise you could draw the wrong conclusions.