Data Recovery Case File · Mac & Apple Ecosystem · Capacity, Not Failure
A Volume With No Free Space Cannot Do Its Own Housekeeping
Her enquiry describes symptoms that look like failure and are arithmetic. A machine whose "storage is totally full to the point it won't really work properly any more. I've bought a 4TB external drive and I'm trying to get my" files across. Nothing is broken — but a system with no free space cannot perform the operations that keep it running, and that includes the transfer she is attempting to escape the problem with.
| Media | Internal system volume at full capacity — host performance severely degraded; external drive acquired for migration; transfer not completing |
| Reported situation | Machine storage entirely full · system performance severely degraded · external drive purchased for migration · transfer of content attempted · transfer not completing satisfactorily · content required |
| Fault class | Capacity exhaustion rather than device failure — system working space unavailable; transfer operations themselves requiring free capacity |
| Equipment used | Capacity distinguished from failure before any recovery assumption · free space established before any transfer was attempted · drive health confirmed by self-reported attributes · migration sequenced in stages with verification at each · destination verified by opening before source deletion |
The decode: what a full volume cannot do
What an operating system needs free space for, continuously: temporary files while applications work, virtual memory when physical memory runs short, caches, logs, indexes, and scratch space for its own maintenance. None of that is optional, and all of it requires somewhere to write.
What happens when there is nowhere: applications fail to save, operations abort partway, the system swaps constantly against a volume that cannot accommodate it, and everything becomes extremely slow. Those symptoms are indistinguishable from a failing drive if you do not know the cause — which is why this arrives as a recovery enquiry.
Why the transfer keeps failing, which is the cruel part: copying files is itself an operation requiring working space. The system needs somewhere to stage, to track progress, and to write temporary state — so the very thing she is doing to solve the problem is the thing the problem prevents.
So the order matters and it is counterintuitive: free space first, transfer second. Even a modest amount changes the behaviour dramatically — emptying the trash, removing obvious large items, clearing downloads and caches. The goal is not tidiness; it is giving the system room to operate.
Why the trash is the first place to look: deleted items still occupy space until it is emptied, and on a machine that has been full for a while there is frequently a great deal in there. That alone sometimes resolves it.
What to check before assuming the drive is healthy: its self-reported statistics. A machine can be both full and failing, and the two produce overlapping symptoms — reading the drive's own figures separates them in seconds.
How to do the migration once there is room: in stages rather than all at once. Move one large category, verify it by opening files at the destination, then delete from the source — which frees more space, making the next stage easier. Repeat.
Why the verification step is not optional: deleting from the source on the strength of a completed progress bar is how a capacity problem becomes a data loss. Open something from the new drive before removing anything from the old one, every time.
On the bench
Capacity was distinguished from failure before any recovery assumption — an operating system requiring free space continuously for temporary files, virtual memory, caches, logs and maintenance, so exhaustion produces slowness and aborted operations indistinguishable from device failure. Free space was established before any transfer was attempted, copying itself requiring working space. Drive health was confirmed by self-reported attributes, a volume being capable of both conditions at once, and migration sequenced in stages with verification at each.
The outcome
Capacity separated from failure, free space established before any transfer, drive health confirmed independently and the migration staged with verification. Free assessment, and no charge where the answer is capacity rather than a fault. The decode: your machine is full rather than broken, and a system with no free space cannot write temporary files, swap, or maintain itself — which produces exactly the symptoms you describe. It also cannot complete a transfer, because copying needs working space of its own.
Machine barely working because storage is full
Empty the trash first — deleted items keep occupying space until you do, and on a machine that has been full for a while that alone sometimes fixes it. Then remove obvious large items to create real headroom, because a system with no free space can't write temporary files, use virtual memory, cache, log or maintain itself, and that produces slowness and failed operations that look exactly like a dying drive. It also can't complete the transfer you're attempting to fix it, since copying needs working space of its own. Then migrate in stages: move a category, open files at the destination to verify, delete from the source, repeat.
Empty the trash first — or call Oxford Data Recovery on 01865 593000; capacity distinguished from failure, drive health confirmed independently, migration staged with verification before any deletion.
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.