Recycle Bin ($I and $R Files)
Also called $I file, $R file, INFO2, Windows recycle bin forensics.
- PLATFORM
- Windows
- CATEGORY
- Deletion and Recovery
- INDEX
- 22 of 36
- PROVES
- 5 findings
- CANNOT PROVE
- 5 limits
- QUESTIONS
- 3 answered
Deleted files moved to the Recycle Bin are stored as a renamed copy of the content plus a metadata file recording the original path, original size and the deletion time.
Where it lives
C:\$Recycle.Bin\<user SID>\ — $I metadata files paired with $R content files
Name the location in the preservation request rather than describing the artifact in general terms. A request that asks for the record by its path is one the responding party can act on and one a court can enforce; a request for “all forensic evidence of recycle bin ($i and $r files)” is neither.
What it records
When a file is sent to the Recycle Bin, Windows writes two files into a folder named for the deleting account's SID: a metadata file holding the original full path, the original size and the deletion timestamp, and a content file holding the file's data under a randomised name. Emptying the bin unlinks both. Older Windows versions used a single INFO2 index instead of paired files, and the modern metadata format has itself been revised to support longer paths.
What it proves — and what it cannot
These two panels carry equal weight, deliberately. The right-hand column is not a disclaimer: it is the specific, mechanical reason an inference fails, and it is the column opposing counsel will read back to a witness on cross-examination.
What it proves
FINDINGS THIS ARTIFACT WILL SUPPORT ON ITS OWN TERMS.
- That a file at a specific original path was deleted by a specific user account, at a recorded time
- The file's original size, and — while the content file survives — its complete content
- Deliberate deletion through the shell, as distinct from a file simply disappearing
- A per-account attribution that most deletion evidence lacks, because the SID names the folder
- Bulk deletion patterns, where many metadata files carry closely clustered timestamps
What it cannot prove
INFERENCES IT WILL NOT CARRY, HOWEVER STRONGLY IT POINTS.
- That a file not in the bin was not deleted. A shift-delete bypasses it entirely, as does deletion by any program that unlinks a file directly, and files above the bin's size limit for the volume are removed rather than retained
- That the account holder deleted it. The SID identifies the security context of the deleting process, which includes anything running in that session
- Intent. Deleting files is ordinary behaviour, and the artifact records no reason and no relationship to a preservation obligation
- That an emptied bin destroyed the content. Unlinking normally leaves the data in unallocated space, where carving may still recover it
- The original creation or modification history of the file. The metadata file records the original path, size and deletion time, not the file's own timestamps
How the finding is attacked
An opinion built on this artifact meets these arguments. Each of them is answerable, and each of them is answered before the report is served rather than at a deposition.
- Pointing out that the deletion is consistent with routine cleanup absent evidence of a preservation duty and of awareness of it
- Showing that the SID attribution reaches a session rather than a person
- Arguing that an empty bin is uninformative, since emptying is automatic when the bin's size limit is reached
- Challenging any reconstruction of content from a $R file whose data has since been partly overwritten
What survives, and for how long
Paired files persist until the bin is emptied or its size limit for the volume forces older items out. After emptying, the content often survives in unallocated space until overwritten, and metadata frequently survives in the master file table even where the data does not.
More matters are decided by what an artifact never kept than by what it says, which makes preservation timing the most consequential decision in the matter — and it is usually made months before anyone examines anything. The evidence preservation deadline calculator works from the date you first anticipated litigation.
Questions counsel ask
What does a $I file in the Recycle Bin tell you?
It records the deleted file's original full path, its original size, and the time it was deleted. It is paired with a $R file holding the content under a randomised name. Because both sit in a folder named for the deleting account's SID, the pair gives original location, size, content and deletion time with per-account attribution — an unusually complete record for a deletion.
Does an empty Recycle Bin mean files were permanently deleted?
Not necessarily, and it is not evidence of concealment on its own. The bin empties itself automatically when its size limit for the volume is reached, files above that limit are never placed in it, and a shift-delete bypasses it entirely. Emptying also does not destroy content: unlinked data usually survives in unallocated space until overwritten.
Can you tell who deleted a file from the Recycle Bin?
You can tell which account's security context performed the deletion, because the containing folder is named for that account's SID. That is genuine attribution and it is not attribution to a person. Anything running in that logged-on session — including a script, an installer, or another individual using an unlocked machine — produces the same record.
Terms used on this page
Every term below is defined in the forensic glossary — what it is, why a case turns on it, and what happens when it is mishandled.
- DELETED FILE
- FILE CARVING
- LITIGATION HOLD
- MASTER FILE TABLE ($MFT)
- METADATA
- SPOLIATION
- TIMESTAMP
- UNALLOCATED SPACE
Related artifacts
No artifact carries a matter on its own. These are the records that corroborate, contradict, or supply the timeline this one cannot.
$MFT (Master File Table)
The NTFS index of every file and directory on a volume, holding two independent sets of four timestamps per file plus, for small files, the file's entire content.
$UsnJrnl (USN Change Journal)
A per-volume journal recording every change to every file — creation, deletion, rename, data overwrite — with a timestamp, a filename and a reason code for each entry.
Volume Shadow Copies
Point-in-time block-level snapshots of a volume, often holding an earlier version of a file that has since been altered or deleted — sometimes the only copy of a document as it originally stood.
$LogFile (NTFS Transaction Journal)
The NTFS transaction journal, recording individual metadata operations in order so they can be rolled back — the most granular record of filesystem activity, covering the shortest window.
Whether the recycle bin ($i and $r files)evidence in your matter supports the opinion built on it is a question with a testable answer. Law & Forensics retains court-tested digital forensic expert witnesses and forensic neutrals.
A conflicts check and scoping call follow, normally within one business day. Please do not send privileged or case-sensitive material until conflicts have cleared.
- Can This Artifact Prove That?
Start from the claim rather than the artifact: which records bear on it, and what no combination of them establishes.
- Computer forensics
The examination this artifact is collected and analysed in, scoped to a matter and reported so it can be tested.
- The artifact index
All 36 entries, grouped by what they bear on and filterable by platform.
- Daubert and digital evidence
Why an opinion stated one level too strongly is an admissibility problem rather than a point for cross-examination.
Attorney advertising / expert services. This page describes forensic artifacts and the procedural rules that govern expert evidence in general terms. Artifact behaviour varies by operating-system version, build, and configuration, and every observation has to be verified against the system actually in front of you. Nothing here is legal advice, and it is not a substitute for checking the rules, standing orders, and case law of your own forum.