Don't copy and paste files when testing with URLResourceKey.creationDate

The current app I'm working on right now works off of mostly URLs which are sorted by their creation date. Within my app I move change the location of the file at the URL. I was getting a very weird bug when moving them. The order would be messed up. I'd close the app and run again to find that they're in a different order than before! Did this again and again a new order! Well, macOS and iOS have gotten so fast that when I put the files in the documents folder using iExplorer it put them in within a second. But the creaton date key tracks to the SECOND, not MILLISECONDS! So as far as it could tell they were all made at the same time, causing my script to order them the way it wanted! So, if anyone out there ever has to do the same thing, move the files in one at a time or you'll have bugs that will drive you mad.

Replies

But the creaton date key tracks to the SECOND, not MILLISECONDS!

This is volume-format specific:

  • Many file systems, including HFS Plus, use 1 second date resolution.

  • APFS stores dates at a much higher resolution.

  • There are some outliers. For example, MS-DOS (FAT) use a 2 second resolution.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

So than I misread the date, because this happened on my iPhone running the current iOS. If I remember correctly iOS 11 is APFS. This means that macOS was able to copy and paste multiple files in less than 0.05 seconds. Wow.


What is the date resolution APFS stores Eskimo?

What is the date resolution APFS stores …?

The Volume Format Comparison section of the Apple File System Guide lists it as 1 nanosecond.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

.............wow.....