I started this whole thing just with a general idea that I want to track times across USB devices on MacOS. As I went further down the rabbit-hole, however, I seem to have gotten lost and can’t seem to find my way back without finding more unexplored tunnels.
It seems as if there are more timestamps on MacOS than I’d thought. The more I delve into extended attributes, the more I find.
Take the following, as an example. This is an external HFS+ drive. When running “stat” on the file I get the following (all dates and times are UTC):
- Accessed: 10/17/16 08:22:50
- Modified: 10/12/16 15:18:58
- Metadata Change: 10/14/16 14:09:10
- Born: 10/12/16 15:18:58
So, WHY does the following image show “Last opened” as 10/12/16 15:18 when the accessed time from “stat” shows something completely different?
Obviously this “Last opened” date and time come from somewhere else.
I ran “mdls” on the file and saw the following:
OK, nothing here except the normal stuff. I opened the file and closed it without saving. The metadata shown in Finder now shows the following:
Note that the “Last opened” date now shows a different date and time. Running stat also shows that the last accessed time here has been updated but we already know that isn’t the source of the date and time that we see in Finder so I ran mdls again and got this:
We now see three more pieces of metadata, kMDItemLastUsedDate, kMDItemUseCount and kMDItemUsedDates. The first of which is the date and time displayed in Finder for “Last opened.”
We’ll get to the other two items in just a moment, but first, why track this separately? Why not just used “Accessed” from the catalogue? Well, it appears as if “Accessed” is very generic on MacOS. This can be triggered by right-clicking and selecting “Get info”. It can also be triggered by system events, such as indexing, updates to the file system, and so on. If a user wanted to find all files that had been opened in the last week, for example, the list could be thousands of items long due to automated processes. The kMDItemLastUsedDate, however, is only triggered when a user opens the file. This is not updated by any automated process. If you see this field populated it means that the user has opened this file, at least once, on that volume and you have the date and time of that opening.
The field kMDItemUseCount is almost exactly what you’d expect it to mean. It counts how many times the file has been opened on that volume. The only issue here? It starts at two so you have to subtract one every time you look at this.
The field kMDItemUsedDates is beyond amazing. This isn’t just a single field, but an array. Sadly it only resolves to the date, not time, but every time that the file is opened the date is logged.
Imagine a scenario where someone uses a Mac to copy a file to an external HFS+ drive upon leaving a company. The company finds this out and wants to know what was taken. You investigate the external drive and find that one file was copied. The former employee claims that they copied the file but have never opened it since. A review of the metadata here shows that they’ve accessed it multiple times on multiple days. Your client is happy.
Maybe that is oversimplifying things, but still, you get the point.
So, how many timestamps can one file have? As many as Apple wants it to have, apparently!
As I was looking at mdls output I noticed a couple of other items of interest.
I looked at one of the screenshots I took earlier in the day and found YET MORE timestamps.
Here we have two more arrays, kMDItemUserModifiedDate and kMDItemUserModifiedUserHandle.
The kMDItemUserModifiedDate field is, once again, pretty self explanatory. This is another array that stores the date and time that the file was last saved. The kMDItemUserModifiedUserHandle field gives you the handle of the user that made the change. The two fields are linked.
This example was with a screenshot opened and saved in Preview but the value did not update when I opened and saved it in Gimp.
I saw different behavior when viewing Word documents. Behold:
Here we see two new items kMDItemUserCreatedDate and kMDItemUserCreatedUserHandle. They appear to coexist in much the same way as the prior fields, connecting user to creation.
Here’s where things get murky. There’s two dates listed under this field. I know that the first date is when the file was created. But there is a second date and time for creation. I have no idea what that means or how it is possible to have two creation dates for the same file. I need to look into this more. I tried several things with Word files and could not replicate this.
Every Word file I created had one created date that showed the exact time of creation, however, the kMDItemUserModifiedDate field did not show when I saved the file. The only way I could force this to populate was to “Save as” and save over the top of the original file.
Clearly some of these fields are populated and changed based on their file types and/or the software used to open them. I’d recommend testing this on whatever file types your investigating as the behavior could vary.
Regardless, these could be extremely valuable when trying to reconstruct user activity.
In terms of other filesystems, there is some definite loss of dates and times, depending on what you use.
NTFS does not show or update any of the dates and times discussed here. Obviously I’m just using Tuxera, so other drivers may be different.
ExFAT shows both the kMDItemLastUsedDate and kMDItemUseCount fields. When using “Save As” and overwriting an existing file the fields kMDItemUserModifiedDate and kMDItemUserModifiedUserHandle are populated. However, when saving to a new file neither kMDItemUserCreatedDate or kMDItemUserCreatedUserHandle are populated.
On FAT32 we see both the kMDItemLastUsedDate and kMDItemUseCount fields in use. When using “Save As” and overwriting an existing file the fields kMDItemUserModifiedDate and kMDItemUserModifiedUserHandle are populated. When saving to a new file both kMDItemUserCreatedDate and kMDItemUserCreatedUserHandle are populated.
Like I said, this may well be different for different file types and/or the software used to open them. Please check these yourself on a case-by-case basis.