Data Recovery Case File · Formatted & Logical Faults · Open Is Not Saved
The Document That Was Never Saved
Her enquiry described a loss with no device fault at all, and traced it carefully. Notes taken for a friend ran to "about 120 pages, a second document about 40 pages. I wanted to check spelling, so the document remained open on my computer. Auto-save was not turned on. Around a month later, I restarted my computer. Some documents auto-recovered — I saved those. Neither of mine had recovered, especially not the 120." She then searched the application, the linked cloud folder and the temporary items folder, finding only older material. Her diagnosis is right, and the honest answer is a mixed one. Documents that were only ever open have a thin trail on disk, and where a recovery file was written it is findable — but where none was, there may be genuinely nothing to find.
| Media | Mac system drive — two word-processor documents left open without ever being saved; autosave disabled; machine restarted approximately a month later |
| Reported situation | Documents created and kept open for an extended period · autosave not enabled · some other documents auto-recovered after the restart · the two required documents not among them · application folders, cloud storage and temporary items already searched by the owner |
| Fault class | No device fault — unsaved work with recoverability dependent on whether application recovery files were written and whether they survived system maintenance |
| Equipment used | Drive imaged write-blocked before further use · application recovery and temporary locations examined on the image · free space carved for document signatures and fragments · cloud version history and Trash checked separately |
The decode: what exists on disk when nothing was saved
What "open but never saved" actually means: a document being typed lives in memory. It becomes a file on disk only when it is saved, or when the application writes a copy of its own accord. With autosave off, the second of those is the only trail there was — and applications vary in how often they write recovery copies, how long they keep them, and whether they write them at all for a document that has never been given a name and a location.
Why some documents recovered and hers did not: the difference she noticed is meaningful. The ones that came back were almost certainly documents that had been saved at least once, so the application had a file to write recovery information against. A document that has never been saved has no home to return to, which is precisely why applications are least reliable at protecting exactly the work people most assume is protected.
Why the month matters: and this is the hardest part. Temporary and recovery locations are cleared routinely — on restart, by scheduled maintenance, and when applications tidy up after themselves. A document open for a month generated recovery files repeatedly over that period, and most of them will have been superseded or removed long before the restart. What survives is thin.
Where the remaining chances are: four places, and she has looked at three. The application's own autorecovery folder, which is separate from the temporary items folder and is where the useful copies live. The system's temporary directories, which she has searched. The cloud folder's version history and deleted-items area, which is worth checking specifically rather than just looking at the current contents — history sometimes holds versions the folder no longer shows. And free space on the drive, where a recovery file that was deleted may still be physically present and carvable, which is the part that needs a bench.
The instruction that matters now: stop using the machine as far as possible. Anything still recoverable is sitting in space the system considers free, and ordinary use — installing, updating, even browsing — writes over it. On solid-state storage the window is far shorter, because background housekeeping clears freed blocks within minutes.
The honest limit: if the application never wrote a recovery file for those two documents and no fragment survives in free space, then the work existed only in memory and ended when the machine restarted. That is a real possibility and it should be said rather than discovered after a bill.
On the bench
The drive was imaged write-blocked as soon as possible, because on this fault every hour of ordinary use costs more than any technique recovers. On the image the application's autorecovery locations were examined — distinct from the temporary items folder she had already searched — along with system temporary directories and the caches applications keep for open documents. Free space was then carved for document signatures and fragments, which is where a deleted recovery file survives. The cloud folder's version history and deleted-items area were checked separately, since those hold material the visible folder no longer shows.
The outcome
The recovery locations examined on an image, free space carved for surviving fragments, and the honest limit stated plainly. Free assessment, one fixed written figure including VAT, no recovery, no fee. The decode, for anyone who has lost unsaved work: a document being typed lives in memory and only becomes a file when saved or when the application writes its own copy — so with autosave off, that copy was the only trail; documents that recovered were probably ones saved at least once, which is why never-saved work is the least protected; a month of being open means most recovery copies were superseded or cleared long before the restart; the remaining chances are the application's autorecovery folder, cloud version history, and free space on the drive. Stop using the machine while that is looked at.
Lost work that was open but never saved
Stop using the computer for anything you can avoid — no installs, no updates, minimal browsing. Whatever might still be recoverable is sitting in space the system regards as free, and ordinary use overwrites it; on solid-state storage that window closes within minutes rather than days. Then look in the right place. The temporary items folder isn't where the useful copies live — your application keeps its own separate autorecovery folder, and that's the one worth searching. Check your cloud folder's version history and its deleted-items area too, not just what the folder currently shows. And be prepared for an honest answer: a document that was never saved exists only in memory plus whatever the application chose to write, so if no recovery file was created there may be nothing on the disk at all. Turn autosave on afterwards.
Stop using the machine — call Glasgow Data Recovery on 0141 404 0294; imaged write-blocked, autorecovery locations examined, free space carved for surviving fragments.
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.