Member Avatar for lewashby

When I delete files on any given file system like hard drives that I have mounted to my system or USB stick I get a directory that usualy named '.Trash-1000'. How does that directory work? Do I need to manually delete the .Trash-1000 directory because it might remain taking up storage or does it Linux overwrite anything that's place in that directory? Thanks.

  • 2 Contributors
  • 1 Reply
  • 400 Views
  • 23 Hours Discussion Span
  • Latest Post Latest Post by rubberman

Dani AI

Generated

Short answer: that .Trash-1000 is the per-user “trash can” the desktop environment creates on the root of a mounted filesystem when a file is deleted from that filesystem by a file manager. The number (1000) is the numeric UID of the user who trashed the file (many Linux distributions start regular users at UID 1000). The FreeDesktop.org Trash Specification defines this behavior and the layout: either $topdir/.Trash/$uid (when a shared .Trash with the sticky bit exists) or $topdir/.Trash-$uid, and a trash directory always contains files/ (the trashed items) and info/ (the .trashinfo metadata with original path and deletion date). (specifications.freedesktop.org)

Files inside that .Trash-1000 keep using disk space until the trash is emptied — emptying is the step that actually erases (unlinks) them. To inspect and reclaim space safely, check the directory size and the .trashinfo entries first so nothing needed is lost. Use desktop “Empty Trash” or the command-line tools (gio trash --empty on systems with GIO) or a CLI helper like trash-cli if you prefer a shell workflow. If files were removed with rm, they do not go to the trash — rm unlinks immediately. (docs.redhat.com)

If the goal is to free space on the removable drive only, either empty the trash for that mount or, after verifying contents, delete the contents of .Trash-1000/files and the matching .trashinfo files in .Trash-1000/info. For multiuser shared mounts you can create a top-level .Trash with the sticky bit (chmod 1777) so the DE will use .Trash/$uid instead of creating many .Trash-<uid> directories. Follow the spec’s rules around sticky-bit checks and permissions before changing things. Don’t run rm -rf until you have verified paths and ownership — that’s how data is accidentally lost. (specifications.freedesktop.org)

Quick practical checks (replace /media/DRIVE with your mount):

du -sh /media/DRIVE/.Trash-1000
ls -la /media/DRIVE/.Trash-1000/files
less /media/DRIVE/.Trash-1000/info/somefile.trashinfo

# empty all trashcans via GIO
gio trash --empty

# manual removal (ONLY after you verified contents)
sudo rm -rf /media/DRIVE/.Trash-1000

As noted, emptying the trash is the action that actually frees space; as ’s example shows, the per-mount .Trash-UID folder is simply where the desktop moves deleted files so they can be recovered until you decide to permanently remove them. (specifications.freedesktop.org)

Member Avatar for rubberman

By default, deleting files on Linux systems will put the file/directory into the trash folder (works that way on Windows also). If you empty the trash folder, the files in that directory will be physically deleted. The reason for putting them there is that if you realize you didn't want to delete a file, you can recover it from there. Usually, the trash folder has a file number or size limit. When you exceed those settings, then the oldest files will be deleted first.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.