Small image metadata edits might fail to clone

[wywh]

Short version: I noticed that I must be careful when making very small edits to images which then should be cloned to other disks.

...

Long version: I prefer to set tools like exiftool and GraphicConverter to adjust image and movie file creation & modification dates the same as their internal metadata dates so it is easier to spot errors in dates.

I have my original images and movies on a master HDD and I sometimes edit the files and then use Carbon Copy Cloner.app to clone the master HDD to two identical backup HDDs.

I grabbed a file from the clone disk and wondered why my edits were not present there. AFAIR I had used exiftool or GraphicConverter to add 'ExifIFD:DateTimeOriginal' to some .jpg files that lacked it while the file create & modification dates were already correct. Somehow I could not repeat that error so maybe it was an unlucky coincidence (if I now use exiftool to ADD just 'ExifIFD:DateTimeOriginal' then CCC succeeds to clone it with its default settings).

But on the other hand, if I modify an existing 'ExifIFD:DateTimeOriginal' with +1sec, then CCC fails no notice it. For example: I edit .jpg metadata date with exiftool command:

Code Select Expand

exiftool -m -P -overwrite_original_in_place -ExifIFD:DateTimeOriginal='2000:01:01 12:00:00' image.jpg
...so it now reads as:

Code Select Expand

exiftool -a -G1 -s -Time:All image.jpg
[ExifIFD] DateTimeOriginal : 2000:01:01 12:00:00
...but that edit fails to go to the clone which is still:

Code Select Expand

exiftool -a -G1 -s -Time:All image.jpg
[ExifIFD] DateTimeOriginal : 1988:07:19 21:48:11
I used these exiftool options to preserve other data besides that 'ExifIFD:DateTimeOriginal':

-P -- Preserve file modification date/time.

-overwrite_original_in_place -- Overwrite original by copying tmp file. Mac file creation date, type, creator, label color, icon, Finder tags, other extended attributes and hard links to the file preserved.

CCC author informed me that it uses file size and modification date to determine if a file should be updated on the destination.

And as CCC author adviced, after I set "Advanced Settings > Find and replace corrupted files ON", THEN the file is successfully cloned because CCC then uses MD5 checksum to compare the source and target (which is a disk-intensive and time-consuming task).

I then verified that the MD5 checksum is changed to another value with such exiftool's +1 second change. And the MD5 checksum is reverted back to the initial value if I the change it back -1 second with exiftool.

Code Select Expand

md5 file
I now verified my master image and movie HDD by cloning it to the main clone with that "Find and replace corrupted files ON". It passed with 0 MB cloned so everything was correctly cloned even before that long 2.5 hour check. I have another identical HDD clone but I now decided to just erase those images that were processed with exiftool (with potentially some minor metadata changes that might not previously been cloned) and let CCC do a regular clone which took only 20 minutes for 75 GB. By comparison usually the clone update takes on a few seconds if not much has changed.

BTW, on macOS those tools can readily set dates way older than 1970 but such old dates (1900, for example) are usually reverted to something like 2036 after a reboot. It seems CCC sometimes notices such fluctuations in file dates so it sometimes seems to re-clone such images.

BTW those old 3TB Seagate HDDs are way slower than new SATA SSDs but I still have my main cold archives on them because I have heard that SSD might not be so reliable in long term powerless "cold" storage.

- Matti