How to recover deleted files from the Recycle Bin (even after emptying)

Two recovery scenarios. The trivial one is "file is still in the bin" — restore from the shell. The interesting one is everything after that: emptied bins, shift-deleted files, anti-forensic wipers. The same $I metadata that lets the shell restore a file is also your best map for what to chase on disk when the easy path is gone.

When the file is still in the bin

1. Open the desktop Recycle Bin.
2. Right-click the file, choose Restore.
3. Windows reads the original path from the $I, renames the $R back to the original name, and moves it to that path. If the original folder is gone, Windows recreates it.

For batch restoration from the command line:

PowerShell.exe -Command "(New-Object -ComObject Shell.Application).NameSpace(0xA).Items() | %{ $_.InvokeVerb('Restore') }"

…runs Restore on every item in the bin. Useful when a user mass-deleted in error and you need to undo at scale.

When the bin has been emptied

Emptying removes both $I and $R from the filesystem index, but the underlying NTFS clusters are only marked free. Until something else allocates them, the content is still there.

The single most important rule is the same one disk-recovery has preached for decades: stop writing to the drive. Pull power if you can, image the volume if you cannot. Every browser cache write, every temp file, every Windows Update is a candidate for overwriting the clusters you want.

After the drive is preserved:

1. MFT analysis — the Master File Table $STANDARD_INFORMATION entries for the original paths often survive long after the cluster data is gone. They give you proof of existence, sizes, and timestamps even when the content cannot be carved.
2. USN journal — the USN journal records RENAME_OLD_NAME, RENAME_NEW_NAME, and FILE_DELETE for the original path going into and out of $Recycle.Bin.
3. Volume Shadow Copies — vssadmin list shadows (or Get-VssShadowCopy in PowerShell). A pre-empty snapshot is the cleanest possible recovery.
4. File carving — scan unallocated clusters for known signatures (PDF %PDF, Office Open XML PK headers, etc.). Photorec is the reference free tool.
5. Backup repositories — Windows File History, Veeam endpoint backup, OneDrive Recycle Bin (separate from the shell bin), Google Drive trash. Each has its own retention story.

What the surviving $I is still good for

When the $R content is unrecoverable but the $I is intact (or recovered from a shadow copy), you still have:

That triplet is often enough to prove intentional deletion of a specific file. The content is gravy.

Anti-forensic patterns to watch for

A user who reads forensic blogs reaches for one of three moves:

1. Shift-delete. Bypasses the bin entirely. No $I row exists. Absence of a $I for a known-deleted file is itself a finding.
2. Empty and overwrite. Empties the bin, then drives heavy disk activity to overwrite freed clusters (large downloads, video playback). Cluster recovery becomes much harder.
3. Content wipers. sdelete -p 3 -z, BCWipe, Eraser. The $R content is zeroed, then deleted. The $I may survive long enough to be interesting.

Cross-reference any apparent wipe with Prefetch hits on the wiping tool and AmCache SHA-1 evidence of the tool being present.

Further reading

• $I vs $R files: what's the difference?
• The $I file format explained
• Convert a Windows FILETIME deletion timestamp
• Using the Recycle Bin in a forensic investigation