Copy files from TimeMachine, Date Added: Aug 16, 1970

[umbilical]

I have an SSD dedicated solely to Time Machine. When moving from Sonoma to Sequoia, I performed a “fresh install” (erased and reinstalled using Disk Utility).

After the new Sequoia installation, I just copy all my user folders (documents, movies, desktop, etc) from the Sonoma Time Machine backup. (I do it manually, I don't use the Migration Assistant).

I noticed that all my files and folders have the correct Date Created and Date Modified, but the Date Added shows as August 16, 1970.

All files and folders works fine, it seems are not corrupted or something wrong.

Why does this happen?

I should concern or something wrong?

Thanks

 

[f54da]

IIRC "date added" on finder is kind of weird, from what I gather it's closer to a spotlight attribute not a file system attribute. If you e.g. exclude a directory from spotlight, I've seen in the past that "date added" remains unpopulated. The metadata attribute itself seems recorded in ATTR_CMN_ADDEDTIME attribute (getattrlist). Internally I believe this is represented as some field within FndrExtendedFileInfo.

Weirdness in date added would not surprise me.

Edit: After quick experimentation, the creation time is still recorded in the hfs vnode (within FndrExtendedFileInfo), but it's spotlight/finder that conspires to hide it when spotlight indexing is disabled for a directory. Given that this attribute is not part of the file itself but dynamically set by HFS layer whenever a new node is created though (hfs_makenode), I it wouldn't carry over when files are copied.

APFS is probably similar.

 

[umbilical]

IIRC "date added" on finder is kind of weird, from what I gather it's closer to a spotlight attribute not a file system attribute. If you e.g. exclude a directory from spotlight, I've seen in the past that "date added" remains unpopulated. The metadata attribute itself seems recorded in ATTR_CMN_ADDEDTIME attribute (getattrlist). Internally I believe this is represented as some field within FndrExtendedFileInfo.

Weirdness in date added would not surprise me.

Edit: After quick experimentation, the creation time is still recorded in the hfs vnode (within FndrExtendedFileInfo), but it's spotlight/finder that conspires to hide it when spotlight indexing is disabled for a directory. Given that this attribute is not part of the file itself but dynamically set by HFS layer whenever a new node is created though (hfs_makenode), I it wouldn't carry over when files are copied.

APFS is probably similar.

thank you for your time, I still confused but yes maybe something related.

I disable this on spotlight (attachment) but I don't know...

 

[f54da]

That setting is unrelated, I was referring to disabling actual spotlight indexing (e.g. excluding a directory). But generally i would not worry about date added being set to unix epoch (-ish) when restoring from backup. Basically assuming APFS behaves same as HFS, it's not an attribute that is tied to the file itself.

Date added would be meaningless when doing a bulk restore anyway, because all files would have the same date added (current date), because that is the date the CNID was allocated on the HFS volume.

 

[gilby101]

I noticed that all my files and folders have the correct Date Created and Date Modified, but the Date Added shows as August 16, 1970.

As has been said, Date Added is not a simple file attribute, rather it is a strange bit of metadata relating to both file and folder.

I did some tests running macOS 15.2:

1. Finder drag and drop of a folder from TM to home folder. All Date Added are 12 August 1970.

2. The same, but to a folder excluded from Spotlight. Again, all Data Added are 12 August 1970.

3. Drag and drop from an external APFS (not TM) disk to home folder: Data Added of the folder I dragged is today, but of all files and folders inside have the same Date Added as on the source disk.

Neither was what I expected!! In both cases, I was expecting the Date Added to be today because today is when I was adding them to the destination.

1 and 2 above suggest that this is not a Spotlight indexing question.

I do wonder if this has changed with some version of macOS.

The TM copy is odd (bug? or design flaw?). But I am not worried about file integrity.

 

[f54da]

Note that TM used to hardlinks. Most likely that is why this is an issue, it's noted that ATTR_CMN_ADDEDTIME has weird behavior when hardlinks are involved.

That said with APFS I don't believe hardlinks are used anymore, but it's possible the snapshot mechanism somehow causes issues with this attribute