Failure when setting file modificationDate

Question

LeonardoDev OP

Created Nov ’24

Replies 2

Boosts 0

Participants 3

I properly copy a scrFile to a dstFile with

mManager = [NSFileManager defaultManager];
[mManager copyItemAtPath:srcPath toPath:dstPath error:&error];

but on "some destination disks" the dstFile gets a modificationDate with truncated milliseconds. For instance, with this format "yyyy.MM.dd - HH:mm:ss:SSS" I visualize

srcDate = 2024.11.03 - 12:42:35:772 dstDate = 2024.11.03 - 12:42:35:000

After the copyItemAtPath I even unsuccessfully tried to set the dstFile modificationDate this way

NSMutableDictionary	*dstAttrs = [NSMutableDictionary dictionaryWithDictionary:[mManager attributesOfItemAtPath:dstPath error:nil]];
    
    [dstAttrs setObject:srcDate forKey:NSFileModificationDate];
    [mManager setAttributes:dstAttrs ofItemAtPath:dstPath error:nil];

Again, the dstDate is 2024.11.03 - 12:42:35:000. I unsuccessfully tried even

FSSetCatalogInfo(&dstRef, fsInfo, &srcFsCatInfo);

No way. I noticed that the destination disk is an USB External Physical Volume, Mac OS Extended (Journaled) with "Ignore Ownership on this volume" on. Could this flag be the cause of the trouble? Shouldn't this flag regard only the files ownership?

This issue brings another trouble. Since the srcDate and the dstDate are not equal, my macOS app performing a backup, copies the srcFile to the dstFile again and again.

To workaround the trouble, I actually compare srcDate with dstDate after truncating their milliseconds. But I guess this is not a good practice.

Any idea on how to fix this trouble? Thanks.

P.S. I attach here the disk info

Disk_Info.txt

Volume name : macOS_10.2.6
Volume type : Physical Volume
BSD device node : disk9s2
Mount point : /Volumes/macOS_10.2.6
System : macOS 10.12.6 (16G29)
File system : Mac OS Extended (Journaled)
Connection : USB
Device tree path : IODeviceTree:/PCI0@0/PEG1@1,1/UPSB@0/DSB2@2/XHC2@0
Writable : Yes
Is case-sensitive : No
File system UUID : 667D1DF9-5ECB-3F9B-92F5-0698601635AF
Volume capacity : 549.999.996.928
Available space (Purgeable + Free) : 43.593.959.137
Purgeable space : 715.675.361
Free space : 42.878.283.776
Used space : 507.121.713.152
File count : 2.681.683
Owners enabled : No
Is encrypted : No
System Integrity Protection supported : Yes
Can be verified : Yes
Can be repaired : Yes
Bootable : Yes
Journaled : Yes
Disk number : 9
Partition number : 2
Media name : 
Media type : Generic
Ejectable : Yes
Solid state : No
SMART status : Not Supported
Parent disks : disk9

Answered by galad87 in 816060022

HFS+ doesn't store milliseconds, only number of seconds since midnight, January 1, 1904, GMT, so there is no way to do what you want to do.

Modification date is not super reliable, so while it could be useful to check for changes, it's not enough (even in a hypothetical world where HFS+ stores milliseconds).

Boost

Answer 1

galad87 OP

Nov ’24

Accepted Answer

HFS+ doesn't store milliseconds, only number of seconds since midnight, January 1, 1904, GMT, so there is no way to do what you want to do.

Modification date is not super reliable, so while it could be useful to check for changes, it's not enough (even in a hypothetical world where HFS+ stores milliseconds).

1

Answer 2

DTS Engineer OP

Apple

Dec ’24

LeonardoDev wrote:

So now I'm curious to know which other volume formats don't store milliseconds on the modificationDates

It’s actually worse than that. FAT famously stores dates with a 2 second resolution O-:

which other volume formats don't store milliseconds

Lots of them. If you’re curious, the Wikipedia article for the most common file systems has a Date resolution field with the details.

Annoyingly, neither the range nor the resolution are exposed at the API level, so you can’t tell how trustworthy your dates are.

Also, many older volume formats store the dates on disk in local time, which making things tricky.

which other data are more reliable?

That depends on what you’re using the dates for.

ps It’s better to reply as a reply, as explained in Quinn’s Top Ten DevForums Tips.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0