How to recover files after emptying the Recycle Bin

What emptying the bin actually does

Deleting a file to the Recycle Bin is a move, not a deletion: Windows relocates it into a hidden $Recycle.Bin folder on the same drive and writes a small companion record holding its original path and the date. Nothing about the file's contents changes, which is why restoring from the bin is instant even for a 40 GB video.

Emptying the bin is the actual delete. Both the file and its companion record are removed from the file table, their table entries are marked reusable, and their clusters go back on the free list. The bytes are not touched. From that moment the file is exactly as recoverable as any other deleted file — and exactly as vulnerable to being overwritten by the next thing Windows writes.

Two things to check before you install anything

Both are free, both take a minute, and both are better outcomes than recovery, because they give you the file with its name and history intact.

1. OneDrive's own recycle bin. If the folder was synced, deleting locally sends the file to OneDrive's web recycle bin, which keeps it for a period of its own regardless of what your local bin does. Sign in to OneDrive in a browser and look there first.
2. File History or a backup. Right-click the folder the file was in, choose "Restore previous versions", and see whether Windows has a copy. If File History was ever switched on for that drive, this is the cleanest possible recovery.

If neither has it, recovery software is the remaining option, and the rest of this page is about doing it without making things worse.

Recovering the files

1. Stop writing to the drive the files were on. If it was an external drive or a USB stick, unplug it. If it was C:, stop downloading, installing and saving — and do not defragment, run disk cleanup, or accept an offer to optimise the drive.
2. Install the recovery software somewhere else. Installing onto the drive you are recovering from is itself a write, in the same free space your files are sitting in. A spare USB stick is enough. If the files were on the system drive and they matter a great deal, the safest route is to shut the machine down and read the drive from another computer.
3. Scan the drive read-only. Point the software at the drive letter the files were deleted from and let it read. Reading changes nothing, and you will see the files appear as they are found.
4. Recover to a different drive, then check what you got. Open the important files. A file can come back at the right size and still be missing pieces, and you want to know that while the source drive is still untouched.

What NTFS still remembers about your file

Windows drives are NTFS, and NTFS keeps two journals that make emptied-bin recovery noticeably better than it would otherwise be. Most recovery tools read only the current file table; these are records of what the table used to say.

• The change journal ($UsnJrnl) is a list of events — what happened to which file, in which folder, and when. A file whose table entry has already been given to something else still has a name and a parent folder here, and its deletion carries the actual date and time. That is often the difference between a numbered file and Thesis_final.docx in the folder it came from.
• The transaction log ($LogFile) holds the information NTFS would need to undo a change it was about to make. The undo of "free this record" is the entire record, including the list of where the file's pieces are on the disk. So a file whose table entry has already been reused can sometimes be recovered in full rather than merely identified.

Unlost reads both, and reports it when the journals show that another file was later given your deleted file's clusters — a fact written down by Windows at the time, rather than an inference from what the drive looks like now.

What to expect from the results

Emptied-bin recovery is one of the better cases, but it is not uniform:

• Names and folders usually survive, because the file table entry is still readable. Where the original folder cannot be established — the parent entry was reused, or the chain of parents does not resolve — a file is placed in a folder named [unknown folder] rather than guessed into a plausible wrong one.
• Small files often come back perfectly. A file below roughly a kilobyte lives inside its own table record on NTFS, with no clusters at all, so if the record is readable the file is complete.
• Large files are the ones at risk, because they occupy many clusters and only need a few of them reused to come back damaged. Which stretches survived is shown before you recover anything.
• An internal SSD is the exception. Files emptied from an SSD's bin are frequently unrecoverable within minutes, whatever you do. Why deleted files can be recovered — and when they can't explains the mechanism and how to tell.

Questions about emptied bins

Is Shift + Delete different from emptying the bin?

Not in any way that matters here. Shift + Delete skips the bin and deletes the file directly; emptying the bin deletes it a moment later. Both leave the contents on the drive and both are recovered the same way.

How long do I have after emptying the Recycle Bin?

There is no expiry, only overwriting. On a drive nothing writes to, the files stay recoverable indefinitely. On a system drive in daily use, minutes can be enough to lose some of them. Stopping use of the drive matters more than acting quickly.

I emptied the bin weeks ago. Is it worth trying?

Yes, if the drive has been quiet since. Read-only scanning costs nothing but time, and it tells you what survived instead of leaving you to wonder. On a busy system drive after weeks, expect a partial result.

The files were on a network drive or a NAS. Does this work?

Not over the network — recovery has to read the physical disk, and a network share only offers files the server admits to having. Deleting from a network location also bypasses your local Recycle Bin entirely. You would need to connect the disk itself to a computer. Disks pulled out of a NAS are usually ext4 or XFS, which Windows will not mount; Unlost reads those directly, so the drive shows its files even though Windows calls it unallocated.

Why did nothing go to the bin when I deleted from a USB stick?

Windows does not use the Recycle Bin for removable drives by default — files deleted there are deleted immediately. That is not worse for recovery: a USB stick is a good case, because almost nothing writes to it in the background.