I need to have all deleted files for all users go into a folder on another drive. Is this possible? If so, what are the commands to permanently move the trash folder(s)? The operating system is Debian Jessie. Thanks.

So, I am busy writing myself a program to move and restore items from my trash (recycle bin), currently I can move it to the trash, but if I try to restore it from the trash using a file manager, it fails. The trash directory is located at ~/.local/share/Trash and it has 2 folders inside it, files/ to store the files you want to delete and info/, to store the data about the files. I got the file naming correct in the application, so that is not the problem, and I got the details that gets stored in the info/ folder correct as well. Yet, if I delete something with my file manager and then recover it from the trash, there is no problem, but when I move it to the trash with my code, it can only be recovered by manually moving it... Here are some examples of my application: $ nrash todelete.txt > Moved to trash The above creates this: (inside Trash/files) todelete.txt (inside Trash/info) todelete.txt.trashinfo Inside the **.trashinfo** file, the following resides: [Trash Info] Path=/home/netsu/Documents/todelete.txt DeletionDate=2021-10-08T18:24:04 In a .trashinfo for a file deleted from the filemanager instead, you would find this: [Trash Info] Path=/home/netsu/Documents/pp.txt DeletionDate=2021-10-08T18:25:02 The two are exactly the same, yet don't work the same... Is there something I'm missing about moving things to the trash? Why can the file that was placed there by the file manager be restored, but the one I placed there can not? Is this the universal way the trash works on Linux distros, or does it change depending on distro/desktop environment? Note: My file does appear inside Trash when I open it in the file manager, but I can't restore it. - Distro: Solus - DE: MATE - File Manager: Caja

I am running a preinstalled version of ubuntu 18.04 but cannot find Trash folder. The typical places don't have the folder. ~/.local/share/Trash <-- does not exist /root/..../Trash <-- does not exit The directory should most likely be here but it's not /home/$USER/.local/share/Trash <---does not exist Hmm ... so I ran a search as follows: sudo find / -type d -iname Trash The output was not nice: find: ‘/run/user/1001/gvfs’: Permission denied /home/$USER/.local/share/evolution/..../trash /home/$USER/.cache/evolution/.../trash /user/share/doc/HTML/.../trash and that's it! By ... I meant there are various directories ending with /trash. But that's useless to mention anyhow since we are not really finding the TRASH can. (Note that I do see a Trash bin on my Desktop, which is ironic. And yes it is empty.) Question is, where is my TRASH FOLDER ? And why do I receive the following output when I run the find command find: ‘/run/user/1001/gvfs’: Permission denied

I have a DNS-321 NAS drive which apparently runs Linux, so I logged in via ssh and I see .Trash-500 and .Trash-1000 directories. I realize that they're for trash, but why do I need two? Inside of them I see expunged, files, and info directories -- what are those for?

Nautilus trash do not move file to trash bin on btrfs file system instead it deletes them permanently. Thunar seems to do the same thing, and it seems related to lower level library implementation of the trash bin. I added a new directory ~/.local/share/Trash/ that allows the file manager Nautilus and Thunar to use the trash bin however it works only for deletion that occurs from the same subvolume. Trashing from any other btrfs subvolume or partition triggers permanent deletion. Calibre, the ebook library manager, has a different behavior. My calibre library is on a different subvolume than my home. When I delete books from the Calibre manager, it moves the books to a hidden directory .Trash-1000 under the root of the subvolume where the Calibre library is stored. However this hidden directory is not taken into account by the trash bin therefore the books stay hidden occupying space until I finally discovered them by chance. I don't think Calibre is wrong here because it looks like the way trash bins are managed on external media in ext3/4 file system. Emacs function (delete-file) manage to use the trash bin for different subvolumes and even more amazing it uses the trash bin ~/.local/share/Trash/ for other partition on different disks. So it does the job perfectly. - Do you know a desktop file manager than could work with the trash bin across different btrfs subvolume ? - Do you know a way to prevent some softwares such as calibre to move the files to a hidden spot while you think they are deleted ? - It seems the libraries gvfs and glib/gio are used to manage the trash bin. The softwares I mentioned are all calling different OS functions when it comes to file deletion and the result is not consistent. Anyone has tracks about how trash bins could be managed correctly ? As far as my research goes, the problem seems to be older than 5 years https://bugs.launchpad.net/glib/+bug/1442649 I have been using btrfs for a long time with this downside, but I am curious to see how other people deal with this problem especially since btrfs becomes more popular and seems to be proposed in some linux distribution installer. GNU/Linux 5.15.2-2 Manjaro Gnome: 41.1

I have enabled auto-delete files older than 30 days in Dolphin trash settings. See https://docs.kde.org/trunk5/en/kio/kcontrol5/trash/ . However, the check seems never to happen. 1+ year old files still exist in the trashcan. I have read here (https://discuss.kde.org/t/wastebin-auto-delete-doesnt-work/3111) that the check only happens when a file is trashed using the KDE API. So I tried to manually trash a file in Dolphin (instead of using gio trash) and it still does not work. Any ideas? Trashing a file older than 30 days doesn't delete it. It is just moved to trash (as expected). I expect the 30 days count beginning the day when the file was moved to trash. This info is available in Dolphin.

From what I gather, the idea of a "trash can" is of Windows descent, and was to make a user's life easier. However, when I go to delete a file, *I don't hit delete unless I know I don't need it and will never need it ever again. Period.* I'm currently running OpenSuse and the trash can is a confusing "feature" (as I can't seem to find WHERE it is) that sometimes even creates cute little directories on my flash drives for trash. Basically put, I don't like the trash can idea. Is there a way I can "turn it off"? I'm assuming it's a filesystem thing, so it might be harder to do then I predict. Basically, I would like to perform a rm -rf on the file that is selected (-r in case it is a directory). Is this at all possible?

I have defined in Mutt two "trash" macros -- one for the Trash folder (just mark as deleted and sync) and one for the remaining folders (save into Trash and sync): folder-hook . 'macro index "s=Trash^"' folder-hook =Trash 'macro index "^"' Together with set delete = yes this results in messages immediately being expunged, no questions asked. Such a behaviour is fine outside the Trash folder, however, I'd like Mutt to ask for confirmation before messages are deleted from Trash. The only workaround that I have come up with so far is not to sync in the macro (i.e., use only `` there), thus having to live with deleted messages being present until I sync manually. (Which is not ideal...) Is it possible to change this setup so that -- in Trash -- Mutt would ask for confirmation before actually marking the messages as deleted and expunging them? Thanks.

Say I just moved a file to trash from a file manager or using a command-line implementation such as kioclient move my_file trash:/. Can I restore it with a single, non-interactive command? [trash-cli](https://github.com/andreafrancia/trash-cli) can restore files, but only (I believe) by selecting them interactively.

In Debian the /root/ directory is so big but du show nothing inside it. root account is just a supervisor/administrator/superuser user, there is no folder for this account in home directory. This extra account created just for supervision is installed by default in Debian.

On archlinux with gnome 3.16.1, in some directories, for example /srv/http/website/public/img/ I don't have options to delete a file , or move to trash, in the rightclick context menu . I have to use shift+del to delete a file. In others, like /home/username/ I have these options. It also seems, that I am the owner of the files in both cases and have rwx permissions. What else could be the reason?

I have a file named "1" maybe it was created by using the wrong command when using redirect. Such as:

commond 2>&1 1>/dev/null

When I try to empty the trash, the file named "1" is unable to delete. I have tried to delete the folder /home/$USER/.local/share/Trash, but it doesn't work at all.

I am working on a Trash implementation and would like to store a log for every deletion. I have reviewed the [Freedesktop Trash Specification](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html) but couldn't find any information about where to store a trash log. What would be the best and most logical place to store a trash log? I have considered several options including: - Storing the log file in .local/share/Trash/info/trashlog.trashinfo, together with the other Trash Info files. - Creating a separate directory for the log file, such as .local/share/Trash/trashlog, to avoid cluttering the directory with other files. - Storing the log file in the top directory of .local/share/Trash, alongside the files and info directories. - Storing the log file in /var/log, where logs are usually stored. - Not storing a trash log at all, if it is considered unnecessary or pointless. Please provide your recommendation on the most appropriate location for storing the trash log, and explain why that location is the best choice. Thank you.

I'm currently trying to able the Trash feature in a NTFS partition mounted automatically on boot. To do that I'm using the permissions option in my fstab: UUID=1CACB8ABACB88136 /media/FILES ntfs defaults,permissions,relatime 0 0 then I changed the permissions: sudo chown :users -R /media/FILES/ sudo chmod g+rwx -R /media/FILES/ It works great except I continue to not have the trash feature. I can read, write, execute being member of the users group but I cannot use the Trash feature in Nautilus, only permanent delete. Any thoughts ? BR

Apologies if this is the wrong place to ask. (Can you suggest a better one?) I'm setting up a brand new Macbook Air (Oct 2022) for an older neighbor. The ISP is att.net The email protocol is standard SMTP, and the server is smtp.mail.att.net . One quirk: AT&T uses OAuth to verify client connections, and they have a page telling you to set up a "secure key" to access your email. The webpage describing that is [https://www.att.com/support/article/email-support/KM1240308/](https://www.att.com/support/article/email-support/KM1240308/) . I did that for the old Macbook that this new one is going to replace. And carried it forward to the new Macbook, which does support OAuth in the current email client, but I left the OAuth avoidance procedure in place. The problem (on both old and new Macbooks) is that incoming email arrives in the Trash folder instead of in the Inbox folder. I was on the phone with AT&T support in the Phillipines for an hour before I finally realized that they knew nothing whatever about email on any level, but would be nice to me for as long as it took for that to sink in. We've been moving all the incoming email into the Inbox manually and everything works perfectly from there. Any ideas on how to fix this? I set up a test account (with neighbor's credentials) on a different Apple computer, and the new test email account has exactly the same problem. Next I will try removing the OAuth avoidance protocol and reverting to the older process. Web searches reveal that other people have hit this issue, but no good remedy has been found so far. Help!

I want to restore I file I deleted accidentally. I cannot go to the trash/wastebasket folder and simply restore the file, because I've no idea what the file was. I deleted it by accidentally pressing the delete key while the screen focus was on a Thunar window. (This is a particular hazard when you have a mechanical keyboard and human fingers). Thunar does not show deleted dates, so it is not possible to simply sort the files in the trash/wastebasket folder. But if I right-click on a deleted file in the wastebasket, and look at files properties, I see that files in the wastebasket do have a "Deleted" date property. How do I list the files by deleted date in a terminal. And how do I open the wastebasket folder in a terminal? And if the wastebasket folder is virtual, and the file properties given a deleted date stored in some other place, where is that place and how do I query it? (I see that if I look in ~/.local/share/Trash/files/, it looks like the same files as are in the wastebasket that you navigate to from the Thunar side-panel icon. But the files in ~/.local/share/Trash/files/ do not have "Deleted" date as an attribute when you right-click to see their properties).

I'm trying to set up shared home directory for two Linux installations and thus I'm using bind-mounts. My user is named dbz and his home directory is /home/dbz. I also have shared directory /home/shared where I store my shared files (this folder is also owned by user dbz). I mount another directories from this shared directory into my home directory using binding: mount -B /home/shared/work /home/dbz/work This solution solves my needs and the only issue I have and don't know how to resolve is - when I'm trying to delete a file or directory from mounted directory I cannot delete it to trash, only permanent deletion is possible. For example: - deleting file /home/shared/work/test.txt: OK, because deleting right from the directory where the file test.txt resides;
- deleting file /home/dbz/work/test.txt: CAN'T, because... by the way, because what? do bind-mounts have some restrictions on file deletion? Finally [an issue submitted to bugzilla.kernel.org](https://bugzilla.kernel.org/show_bug.cgi?id=70831)

When I am in another drive, I only have the option to delete files permanently, and cannot send files to trash. If I log in as a root user, however, I am able to send files to trash. The drive has a .Trash-1000 folder, with root as the owner, and permissions drwxrwxrwx, so other users should have access to it but they can't. * **OS:** Arch Linux * **Kernel:** 5.12.8-arch-1 * **DE:** Gnome 40.1 * **File Viewer:** Nautilus 40.1 * **Drive Type:** NTFS **EDIT:** Could it be because the drive is NTFS, it doesn't support sending files to the trash?

So here is my problem I have a pretty strange file that I can't get out of my computer. I tried pretty much everything. First I used software like CleanMyMac, TrashIt, CCleaner etc... None of them was able to do anything. I tried to throw it to the trash and "secure trash it". It did not complete, so I finally aborted it. I then tried to use the terminal with a sudo rm -R but no: still there. The file is untrashable because it seems not to exist... Here is a view of what I got: sh-3.2# sudo rm -R /Users/Mawel/.Trash/Tunnelblick.app rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Resources: No such file or directory rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Versions/Current: No such file or directory rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents/Frameworks/Sparkle.framework/Versions: Directory not empty rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents/Frameworks/Sparkle.framework: Directory not empty rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents/Frameworks: Directory not empty rm: /Users/Mawel/.Trash/Tunnelblick.app/Contents: Directory not empty rm: /Users/Mawel/.Trash/Tunnelblick.app: Directory not empty Is it basically telling me that there is nothing there and I can't delete nothing? EDIT -- I tried some of your answers especially the one where I force the remove of each file one by one. Here is a sample of what happen : sh-3.2# cd Sparkle.framework/ sh-3.2# ls -al total 8 drwxr-xr-x@ 4 root wheel 136 22 jan 2014 . drwxr-xr-x@ 3 root wheel 102 17 jan 2014 .. lrwxrwxrwx@ 1 root wheel 26 22 jan 2014 Resources -> Versions/Current/Resources drwxr-xr-x@ 3 root wheel 102 9 fév 2014 Versions sh-3.2# sudo rm -f Resources sh-3.2# ls -al total 8 drwxr-xr-x@ 4 root wheel 136 22 jan 2014 . drwxr-xr-x@ 3 root wheel 102 17 jan 2014 .. lrwxrwxrwx@ 1 root wheel 26 22 jan 2014 Resources -> Versions/Current/Resources drwxr-xr-x@ 3 root wheel 102 9 fév 2014 Versions sh-3.2# EDIT 2 -- Thanks to DisplayName I finally manage to remove them by moving them to the /tmp folder and cleaning it.

I have a 32 GB USB flash drive. When deleting files from the drive where the drive is plugged into a Ubuntu 16 laptop, it creates a folder called '.Trash-1000' This .Trash-1000 folder contains two folders which are 'file' and 'info' where file contains the files I have deleted and info contains metadata about those files. The issue is this .Trash-1000 folder takes up space because it holds a copy of the deleted file. I then have to eventually delete the .Trash-1000 folder when it starts filing up after multiple deletes. Is there a way to disable this feature on the USB drive?