Copying Files with macOS Finder: Data Loss Bug

2017-12-18 • SEND FEEDBACK |
Related: Apple, Apple Core Rot, Apple macOS, Apple macOS High Sierra, macOS Finder

Update June 2018: the issue remains unfixed as of macOS 10.13.5.

...

Tonight I returned from a trip and I needed to copy about 234GB from one drive to another.

I canceled that copy about 94GB in, because I realized that I wanted updated hashes (see diglloydTools IntegrityChecker). File hashes are the only good way besides 'diff' to guarantee bit-for-bit identical files, and 'diff' doesn't work if the original files are not available, and takes longer—and my intent was to delete the files off the original drive once copied. With backups, the case is the same—one wants to check the integrity of the backup files, but without the originals that were backed-up.

In resuming the file copy after bringing hashes up to date, the macOS Finder volunteered to “continue the copy”. But what it did NOT do was to check whether any of the files it had already copied had changed-which they had, dozens of them.

Had I resumed the copy then deleted the files off the source drive (my intent all along), the changed files would not have been copied. I would then have deleted the original folder off the source drive. This is potential DATA LOSS and it is just one of many examples of recent issues with Apple quality control.

One could argue: “that user should have known that files were changed and it isn’t the fault of the macOS Finder to actually keep data loss from happening—the user is the problem, he should have realized it was his responsibility to not screw up and to not accept the 'continue' dialog”.

Alrighty then. This is NOT the only data loss Finder copy bug I have seen: I have seen it silently fail (no message or error of any kind) and then finish, apparently done, but with files and/or folders uncopied. Network copies are particularly susceptible to this, if the Finder doesn’t simply fail due to its own bugs (frequent). At least in that case an error dialog appears.

I expect macOS to protect my work, not offer to destroy it. In my view, these kinds of bugs in macOS Finder are not an accident. Rather, they are the result of longstanding quality control problems with Apple software, and now running rampant. I first called this back in 2013 as Apple Core Rot. That message is finally getting through to the “experts” who could not see an emperor with no clothes all these years. Five years to recognize the rot?

What I want to see is the next macOS do *nothing* to add new features, to focus solely on fixing bugs in every area of the system. Alas, I deem the odds of that to be about nil.

The problems pervade macOS and iOS and are accelerating in severity and frequency. In my view, it is irresponsibility driven by schedule. Being the CEO, Tim Cook bears the ultimate responsibility, so I am not cutting him any slack any longer: this has been going on for 5 years now, at least. He is the CEO, and the buck stops there. He ought to take software quality seriously, and hire or fire as needed until a positive trend is seen as well as to freeze macOS features until most of the outstanding bugs are fixed (including 100% of the data loss bugs).

Jonathan L writes:

A few years ago, I copied one drive to anther by dragging and dropping. This resulted in about 17,000 corrupted files. I now use Chronosync's verified copy for all data migration. I also have started using your diglloydTools IntegrityChecker as well.

MPG: can’t be too careful.