@saagarjha alright, put a little bit more effort into it...

The documentation for MemoryLayout.size is terrible, but via debugging it was clear that MemoryLayout.size(ofValue: x) was returning incorrect values (it was always 8), but MemoryLayout<T>.size gave correct values.

Not sure if I got your whole point in (3). Looks like timespec is just 2 Int-type values, and although I couldn't find the def for __darwin_time_t, the result of MemoryLayout<timespec>.size is 16 which seems to vouch for that idea.

Didn't dive in to the written files with a hex editor; just did spot testing. Thumbnail generation & Date Last Opened updates seemed to work fine before this, and seem to work fine after.

What value were you trying this on? The two should be consistent in their results. The problem with serializing timespec is that it can include padding if you write it out directly, which something that you generally don't want to do.

What value were you trying this on? The two should be consistent in their results.

Well...I guess I was wrong... I could have sworn I saw the debugger showing 8 for both version (UInt8) and timespec. But just tried again and I see that they are consistent. So then everything seems to be equivalent to what it was before.

Did not learn until now that Apple's ARM is little-endian. And found here that __darwin_time_t is expected to be 64-bit also for all 64-bit processors.

Pinging @saagarjha: this is still marked as "changes requested" but should be ready to go. Please let me know of any concerns which are blocking this.

Well my point was we should serialize timespec's members and not just try to splat its contents directly.

I dug into this some more and I don't see why breaking apart the timespec struct is necessary or even wise. I don't see any other version of this struct. We only support 64-bit MacOS. Both x86 & arm64 are little-endian. But I broke apart its fields into an [Int] in my new commit, so see if that is satisfactory.

The only case where this field is being used is to (comments) set "date last opened" attribute. I was able to confirm via Mdls -name kMDItemLastUsedDate {file} that the attribute is set correctly.