Data Recovery Case File · Mac & Apple Ecosystem · The Wrong Answer Online
A Real Read Failure With a Popular Wrong Fix
Her enquiry names an error precisely, which is useful, and puts her at risk of the advice that error attracts. A drive that "suddenly stopped working. It slowed down completely and took ages to display the folders on it. When trying to transfer files from it to another drive, an input/output error kept showing up, ending the transfer." Search that error and the top answers all suggest a terminal command — one written for an entirely different cause, which will do nothing here and involves writing to a drive that should only be read.
| Media | Mac-formatted portable hard drive — progressive access degradation followed by input/output errors terminating file transfers |
| Reported situation | Drive slowing progressively with long delays displaying folder contents · transfers to another drive terminating with an input/output error · error recurring on repeated attempts · contents required |
| Fault class | Physical read failure reported at the file layer — sustained transfer load exposing degrading regions |
| Equipment used | Transfer attempts and cleanup utilities discontinued · readable content secured before further attempts on failing files · imaged write-blocked under per-sector timeouts with weak regions revisited · losses mapped per file |
The decode: what the error means, and why the popular fix is for something else
What the error actually reports: an input/output failure. The system asked the drive for data, and the drive did not return it correctly. That is a hardware-level statement passed up to the file layer — not a filesystem quirk, not a permissions issue, and not something the operating system can resolve on its own.
Why the internet's answer is for a different problem, and this matters: the same error is very commonly produced by a completely unrelated cause — hidden companion files that Macs create on non-native volumes, particularly network shares and older removable media, which can break copies. There is a well-known terminal command that removes them, and it genuinely fixes that situation. So it dominates every search result for this error. It has no relevance to a drive that is physically failing, and running it means issuing write operations across a struggling drive to delete files that are not the problem.
How to tell which you have, and her own message answers it: the slowdown. Hidden companion files do not make a drive slow — they cause a copy to fail on a specific file and nothing else. A drive that has become progressively slower and takes a long time to display folders is retrying reads internally, which is the classic signature of physical degradation. Slowness plus input/output errors during transfer is a failing drive, not a filesystem nuisance.
Why transfers keep dying at the same point: a copy operation stalls when it meets a region that will not read, and retrying restarts the file and hits the same region again. It cannot converge, and each attempt spends more of the drive's remaining margin on the same bad area.
The instruction that matters most: copy everything that does copy, now, before returning to what does not. The healthy majority is sitting on a drive that is actively degrading while attention goes to the files that fail. Working through folders and skipping what errors is the right use of the next hour.
What is done instead of copying: imaging under strict per-sector timeouts, capturing the healthy expanse at speed and revisiting weak regions on later passes, where a sector that failed several attempts sometimes succeeds. Files are extracted from the image with the drive no longer involved.
What not to run: the disk utility's repair function, which writes conclusions back, and anything offering to fix or verify the volume.
On the bench
Transfer attempts and cleanup utilities were discontinued — the commonly recommended terminal remedy for this error addressing hidden companion files on non-native volumes, which is a different cause entirely and would issue write operations across a failing drive. Readable content was secured before further attempts on the failing files, since the healthy majority remains at risk while retries continue. Imaging ran write-blocked under per-sector timeouts with weak regions revisited on later passes, and losses were resolved to individual files.
The outcome
The readable majority secured first, the drive imaged under timeout control and the losses reported file by file. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone meeting this error: the fix that dominates every search result is written for a different cause — hidden companion files on non-native volumes — and running it means writing to a failing drive to delete files that are not the problem. Your slowdown is the tell: that is a drive retrying reads, not a filesystem nuisance.
Input/output errors ending every copy on a Mac
Don't run the terminal command you'll find online for this error — it's written for a completely different cause, hidden companion files that Macs create on non-native volumes, and it dominates the search results because it genuinely fixes that. On a drive that's physically failing it does nothing except issue writes to something that should only be read. Your own description tells you which you have: those companion files don't make a drive slow, they just break one copy. A drive that's become progressively slower and takes ages to display folders is retrying reads internally, which is physical degradation. So copy everything that does still copy right now, before going back to the files that fail — the healthy majority is on a degrading drive while you fight the broken minority.
Skip the terminal fix — call Guildford Data Recovery on 01483 901310; readable content secured first, imaged under per-sector timeouts with weak regions revisited, losses mapped per file.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.