Data Recovery Case File · Solid State & Flash · An Honest Mechanism
The Name Was Written and the Content Never Arrived
His enquiry describes a specific and revealing shape of loss. A project saved onto a stick, and the next day at the studio "all the files were missing and there were only a few titles with nothing on them. I've been trying to put it off for quite a while because I didn't want to face the worst." Titles with nothing behind them are not damaged files — they are files whose names were recorded and whose contents were never written, and that distinction decides whether anything can be done.
| Media | USB flash drive — directory entries present with zero or negligible content length; project files not recoverable from the medium |
| Reported situation | Project file saved to the stick · stick used at a separate location the following day · files not present · a small number of names visible with no content behind them · significant elapsed time before enquiry · content required |
| Fault class | Directory entries created without content commit — write buffer not flushed before removal; content never present on the medium |
| Equipment used | Entry length compared against occupied capacity before any conclusion · imaged write-blocked under strict timeouts · signature carving across the full medium to exclude orphaned content · source machine application artefacts identified as the realistic route |
The decode: two stages, and which one completed
How a file gets created: in two separate operations. The system writes a directory entry — a name, a location and a length — and it writes the content into the space that entry points at. Those happen at different moments, and on removable media they can be separated by a considerable interval.
Why the interval exists: the operating system buffers writes in memory and commits them to the device when convenient, because writing in batches is faster than writing continuously. An application that reports a successful save has handed the data to the system, not necessarily to the stick.
So what a name with nothing behind it means: the entry reached the medium and the content did not. The stick was removed after the directory update was committed and before the data was — which is precisely the window that ejecting exists to close.
Why that is worse news than damage: a damaged file is present and unreadable, and there are techniques for that. A file whose content was never written is not on the device at all — nothing to carve, nothing to reconstruct, nothing behind the name. That is the honest position and it should be said rather than tested expensively.
The check that confirms it, and it is quick: compare the occupied capacity of the stick against the sizes those entries report. If the device reports almost nothing used, the content genuinely never arrived. If capacity is consumed while the entries read as empty, that is a different fault entirely and a recoverable one.
Where the realistic hope lies, and it is not the stick: the machine the project was created on. Production applications maintain autosaves, temporary working files and project backups as a matter of routine, frequently in a folder the user has never opened. If that computer still exists, a version very close to the last save may sit on it.
Why the delay cost nothing here: he has been putting it off, and on this particular fault that made no difference — content that was never written does not deteriorate. The only cost of the delay is anything since overwritten on the source machine.
The habit that prevents it entirely: eject before removing, and check the file size in the folder before walking away. A saved file showing zero bytes is visible in one glance.
On the bench
Entry length was compared against occupied capacity before any conclusion — file creation comprising a directory entry and a separate content write, buffered by the operating system and committed at intervals, so removal between the two leaves a name with nothing behind it. Negligible occupied capacity confirms content that never reached the medium. Imaging ran write-blocked with signature carving across the full medium to exclude orphaned content, and source machine application artefacts identified as the realistic route.
The outcome
Occupied capacity compared against entry lengths, the medium carved to exclude orphaned content, and the source machine identified as the realistic route. Free assessment, and no charge where content never reached the device. The decode: creating a file is two operations — the name and the content — and the system buffers writes rather than committing them immediately. A name with nothing behind it means the stick was removed between the two. Check the machine you saved from: production software keeps autosaves and project backups routinely.
Files that show as names with nothing in them
Check the machine you saved from — that's where the realistic hope is, because production and editing applications keep autosaves, temporary working files and project backups as routine, usually in a folder you've never opened. On the stick itself, compare how much capacity is reported as used against what those entries claim: if almost nothing is occupied, the content genuinely never arrived, and there's nothing to recover because nothing was written. Creating a file is two operations — the name and the data — and the system buffers writes rather than committing them at once, so removing a stick between the two leaves exactly this. Eject, and glance at the file size before walking away.
Check the source machine — then call Oxford Data Recovery on 01865 593000; occupied capacity compared against entry lengths, medium carved to exclude orphaned content, free assessment and an honest answer.
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.