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
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).
