Today I was finding and moving personal images from my work images volume to another volume.
Problem: moving* a file in macOS Finder (macOS 10.13.6) from one volume to another destroys the file dates (moving a file, not just copying it). Sometimes the creation date is set to "0", making it a creation date of 1969. Other times both the creation date and modification date are set to the time of the file-move. Still other times the creation date is set to 1969.
* A regular copy (originals left as is) does not seem to incite the problem, so if using Finder to move files from one volume to another, copy them over, then manuall delete the originals—but MPG strongly recommends using IntegrityChecker to validate the copes, becuase the Finder can silently fail when copying files.
This is irreversible (meta) DATA LOSS.
Investigating further, I found that this metadata loss goes way back for years, with about 50,000 files damaged by the macOS Finder. Nice job, Apple.
Unless I write some code or find a tool to extract EXIF info and set the file creation date to the correct date, the Finder has now destroyed the file dates on thousands of files. With other types of files, it is truly permanent, since most files will not have EXIF info. Update: for image files containing EXIF info, the destroyed metadate can be fixed.
Word to the wise: NEVER, NEVER, NEVER count on the finder to move or copy files of any significance. I have now seen not just this damage to file dates, but outright silent failures for total data loss.
Shame on Apple’s for years of Apple Core Rot and shame on Tim Cook personally for letting this kind of incompetence go on year after year—the buck stops with him (well, lots of bucks stop with him), and he’s now had 6 years to take action.
Below, this file was created 2018-04-18, and never modified. Yet the Finder has set the creation and modification dates to 2019-01-27 (“today”), thus destroying the metadata. This is particularly damaging for photos or videos, since sorting by date/time is very useful.
Sometimes the creation date is set to a value of zero (integer 0 in the creation date field), so there is no creation date shown at all ( “--”).
Sometimes the creation date is set 1969. Here a file created in 2015 now has a creation date of 1969.
The bug applies to folders also: