Linux Trash: freedesktop .trashinfo Files and Deleted Items

What it is

Linux desktops implement "Move to Trash" according to the freedesktop.org Trash specification. GNOME Files (Nautilus), KDE Dolphin, Xfce Thunar, the GTK and Qt file dialogs, gio trash and trash-cli all follow it. When a user trashes an item, the implementation moves it into a files/ directory and writes a small .trashinfo text file into info/ that records the original path and the deletion time.

Command-line rm never touches the Trash. An item found here was therefore deleted through a GUI or a trash-aware tool, which is useful for attribution. A Trash that is empty on an otherwise busy desktop, with a recent info/ directory mtime, points to a user who emptied it.

Where it lives

Per-volume trash folders travel with USB drives. A .Trash-1000 directory on a seized stick proves that UID 1000 on some Linux desktop deleted files from it, even when the host is not available.

What it proves

• The original absolute path of each trashed item (or a path relative to the volume root for per-volume trashes), including files that no longer exist anywhere else.
• When the user trashed it, to the second, in the desktop's local time.
• That the deletion went through a desktop application or a trash-aware tool rather than rm.
• The content itself, as long as the Trash was not emptied.
• It does not record which application trashed the item, and it proves nothing about items removed with rm or shred.

Key fields

[Trash Info]
Path=/home/alice/Documents/Q3%20payroll%20export.xlsx
DeletionDate=2026-09-20T03:14:07

Timestamps

DeletionDate has no time zone. Read /etc/timezone or the /etc/localtime link on the image and convert before merging into a UTC timeline. The .trashinfo file's own birth time (ext4 crtime, XFS v5 crtime) and mtime should match DeletionDate once converted, so a mismatch hints at a hand-edited or copied file.

Moving an item into the home trash is a rename() on the same file system. The inode keeps its original mtime and atime, and only the ctime changes to the moment of deletion. Trashing across file systems copies the data instead, which gives the copy new inode times. The ext4 page explains how to read those times.

Retention

Nothing expires by default. Items stay until the user empties the Trash, restores the item or deletes it from inside the Trash. GNOME offers "Automatically Delete Trash Content" under Privacy, backed by the org.gnome.desktop.privacy keys remove-old-trash-files (false by default) and old-files-age (30 days by default). Check the user's dconf database (~/.config/dconf/user) if the Trash looks too clean. Emptying the Trash unlinks both the .trashinfo and the content, so recovery then depends on unallocated space.

Collection

# Dead box: every user's home trash, plus per-volume trashes on mounted data partitions
cp -a /mnt/evidence/home/*/.local/share/Trash /cases/2026-017/trash/ 2>/dev/null
find /mnt/evidence -xdev -maxdepth 3 -type d -name '.Trash*' 2>/dev/null

# Live, as the user or root
tar -C / -cpf /media/ir/trash.tar home/*/.local/share/Trash root/.local/share/Trash 2>/dev/null

UAC has trash and trash_info artifacts that collect %user_home%/.local/share/Trash for every login user. Velociraptor's Linux.Search.FileFinder can glob /home/*/.local/share/Trash/info/*.trashinfo across a fleet.

Parsing

The format is plain text, so a loop is enough for a timeline:

T=/cases/2026-017/trash
for f in "$T"/*/info/*.trashinfo; do
  p=$(grep -m1 '^Path=' "$f" | cut -d= -f2- | python3 -c 'import sys,urllib.parse;print(urllib.parse.unquote(sys.stdin.read().strip()))')
  d=$(grep -m1 '^DeletionDate=' "$f" | cut -d= -f2-)
  printf '%s\t%s\t%s\n' "$d" "$p" "$f"
done | sort

On a live host, gio trash --list and trash-list (from trash-cli) print the same data for the current user. Do not run gio trash --empty or trash-empty on an evidence system.

Investigator tips

• Hash the files under files/ and compare with files later found on USB drives or cloud sync folders; users often trash the local copy after exfiltration.
• A .trashinfo without a matching entry under files/ (or the reverse) means someone manipulated the Trash by hand or a restore failed.
• Path values under /media/<user>/ or /run/media/<user>/ tie the deletion to removable media; pair them with USB device evidence.
• The file manager usually also leaves a thumbnail and a recently-used.xbel entry for documents the user opened before trashing them.
• Look for .Trash-0 on data partitions: root deleting files through a GUI is unusual on a server and worth explaining.