Apple Core Rot: macOS Finder File Copying: Fails to Replace "dot files" When Replacing a folder = DATA LOSS

2019-03-05 • SEND FEEDBACK |
Related: Apple, Apple Core Rot, Apple macOS, data integrity, diglloydTools, IntegrityChecker, macOS Finder

Apple Core Rot extends to all areas of macOS. See Apple Core Rot: It’s Big Things, and Hundreds of Little Ones, that Together Add up to Chaos and also Apple Quality Control: Enough is Enough.

Prelude

The macOS Finder ought to be rock solid, but it is rife with bugs

In particular, serious bugs exist withi macOS finder file copying. Data loss is a very real possibility. Do not rely on the macOS Finder to copy files! If you must do so, use diglloydTools IntegrityChecker to update the originals, the validate the copy or copies.

Just a sampler of the bugs related to the macOS Finder and file copying:

• One more Finder File Copy Bug: Is it Even Safe to Count on the macOS Finder to Copy Files?
• Apple Core Rot Metadata Loss: macOS Finder Destroys File Dates When Moving Files
• Apple Core Rot: macOS Finder Shows Zero-Size Folders — Very Dangerous if Unaware
• macOS Sierra: Possible Data Loss Scenario
• One Example Among Many of Things that Suck with macOS: Continual Breakdown in Quality Control.
• Apple’s Penchant for IGNORING Data Loss Risks Continues, Unabated: Finder Erroneously Shows Files as Zero Bytes
• OS X Yosemite Finder File Copy: Data Loss.

Replacing a folder doesn’t replace invisible files = DATA LOSS

Replace isn’t really a replace; it’s a “scan and screw it up” algorithm. Your best workaround is to delete the destination folder yourself, then copy a full fresh copy (if even that can always be trusted, which is dubious).

You don’t use or create invisible “dot” files? Well some of your software might. Yikes.

This bug came up while verifying files with diglloydTools IntegrityChecker; it flagged a discrepancy between the originals and the copy. I was able to repeat the bug at will (at least 5 times over two hours).

Conditions under which I verified this bug repeatedly:

• macOS 10.13.6 High Sierra (likelly to be an issue with macOS 10.14.3 Mojave and maybe prior versions also).
• Copying a folder from an APFS volume to a macOS Extended volume.
• Changed file is an an invisible "dot" file (file starting with a "."), in this case ".icj".

It’s unclear if this bug affects only invisible files or whether there might be other conditions under which it might occur. It’s also unclear if the type of file system is involved (did not test).

Steps to reproduce

1. Copy a folder with dot files to another destination (I used ".icj").
2. Change one of the dot files.
3. Repeat the copy. When the Finder offers Cancel or Replace, choose Replace.

PROBLEM: the copied folder contains old data in the invisible ".icj" file.

The bug is easily verified with IntegrityChecker (alternately, your choice of 'diff' program).

Or, the ".icj" file can also be opened and viewed; obviously different content = data loss.

Below is what IntegrityChecker showed after the file copy:

# original folder
diglloyd-iMac:MPG lloyd$ icj status ~/Desktop/TripPhotos/
=========================================================
FILE STATUS SUMMARY for 37 folders 2019-03-05 13:03:29
=========================================================
# With hash: 251
# Without hash: 0
# Missing : 0
# Hashed: 0
# Changed size: 0
# Changed date: 0
# SUSPICIOUS: not available, no hashing done
# copied folder — repeated copies do NOT fix the problem
NEW FILES for /Volumes/Master/TripPhotos/...
_DGL7090.xmp
_DGL7092.xmp
_DGL7093.xmp
_DGL7091.xmp
=========================================================
FILE STATUS SUMMARY for 37 folders 2019-03-05 13:03:39
=========================================================
# With hash: 247
# Without hash: 4		<=== WRONG = data loss
# Missing : 0
# Hashed: 0
# Changed size: 0
# Changed date: 0
# SUSPICIOUS: not available, no hashing done