Summary

it'd be useful to have a way to list and filter files (--larger-than, --smaller-than) with file sizes.

Example

╭───┬─────────────┬────────┬──────────╮
│ i │ Time        │ Path   │ Size     │
├───┼─────────────┼────────┼──────────┤
│ 3 │ 5 hours ago │ /a.zip │  3.0 KiB │
│ 2 │ 5 hours ago │ /b.zip │ 12.1 MiB │
╰───┴─────────────┴────────┴──────────╯

References

example ncdu output:

--- /home/scarf/.local/share/Trash/files -------------------------------------
                                                   /..
    2.1 GiB [####################################] /foo
  763.4 MiB [#############                       ] /bar

I'v got error by trying to remove folder from different filesystem then my /home

trash  Videos/Anime
error: Error during a `trash` operation: Unknown { description: "Path: '\"/home/bartolomey/.local/share/Trash/files/Anime\"'. Message: Invalid cross-device link (os error 18)" }

Videos folder is mounted by

mount -bind /mnt/data/Videos $HOME/Videos

I would like to see trashy in various official distributions.

Linux

Repology can cover status of huge number of Linux distributions.

[![Packaging status](https://repology.org/badge/vertical-allrepos/trashy.svg)](https://repology.org/project/trashy/versions)

Some information here https://repology.org/project/trashy/information needs cleaning up.

MacOS

• brew formulae

Windows

• Scoop: ScoopInstaller/Main#5211

When completing with any input on zsh, all I get is the following error:

_arguments:comparguments:327: doubled rest argument definition: *::: :->trashy

I'm using the aur version on arch.

I get an error every time I try to trash something when the trash is in another dataset:

cd
touch test
trash test
# error: Error during a `trash` operation: Unknown { description: "Path: '\"/home/dominik/.local/share/Trash/files/test\"'. Message: Invalid cross-device link (os error 18)" }

For reference, I have the following ZFS datasets (there are others, but they aren't relevant):
zfs list -r -o name,mountpoint

NAME                MOUNTPOINT
Home                /home
Home/Illode         /home/illode
Home/Illode/Local   /home/illode/.local

If I run:

cd ~/.local
touch test
trash test

it works fine.

This is also the first application I've encountered that has had an issue due to ZFS. I tried trashy-cli and it works fine.
I'm using Arch with the latest everything and installed from the AUR.

You can use miette for better errors its not really necessary but nice to have

dosc:
https://docs.rs/miette/latest/miette/

preview:

When trying to autocomplete for files in a directory I get a ZSH completion parsing error (See below).

OS: Arch Linux
Package Version: 2.0.0-1
ZSH Version: 5.9-4

As I love trashy output I need sometimes more specific time when I put file/folder in trash. If two days ago something was deleted, then what time it was exactly?

---------------------------------------------------------------------
|  i  | Time            |  Date             |     Path              │
|-----|-----------------|-------------------|-----------------------|
|  2  | 2 days ago      | 2022/09/13 16:45  |  /home/user/blablabla |
|  1  | 2 days ago      | 2022/09/13 16:40  |  /home/user/blablabla |
|  0  | 43 minutes ago  | 2022/09/15 12:01  |  /home/user/blebleble |
---------------------------------------------------------------------

when i use trash restore --all this command
i always y again

so, you can like this

trash restore --all -y

just one command ,not user second y

see v2.0.0.

By the way, it is better to have a new release with other dependencies updating.

Hello there,

Trying to install trashy on my MacBook (Intel processor) but I get the below error:

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/empty.rs:52:12
   |
52 |     trash::os_limited::purge_all(items.items())?;
   |            ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/list.rs:64:28
   |
64 |     let mut items = trash::os_limited::list()?;
   |                            ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/list.rs:90:36
   |
90 |             let mut items = trash::os_limited::list()?;
   |                                    ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/restore.rs:49:12
   |
49 |     trash::os_limited::restore_all(items.items())?;
   |            ^^^^^^^^^^ could not find `os_limited` in `trash`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `trashy` due to 4 previous errors
error: failed to compile `trashy v1.0.2`, intermediate artifacts can be found at `/var/folders/3c/4h7rrmnd2s1cjhqysqk345lm0000gp/T/cargo-installEiaubN`

I have been looking for a way to non-interactively restore the latest trashed file from the command line. Other implementations don't allow this, I'm happy to have found one that does :)

I feel puzzled how delete files from bin. I tried:

trash empty

error: Must match something

And then:
trash empty all

0 items will be emptied
╭───┬──────┬──────╮
│ i │ Time │ Path │
╰───┴──────┴──────╯
Are you sure? yes

But everything is still in trash folder. If you could add more info for people without imagination like me, that would be awesome.

trash is too long and doesn't match the project name trashy.

I'm thinking of changing the name to something shorter. Some ideas:

• th
• ta
• tm

Expected behavior

When a dead symlinked file is deleted, it should be able to be cleared from the trash directory

Actual behavior

When a dead symlink is deleted, it correctly goes into the trash directory, but the trash restore/empty commands no longer work as long as the dead symlink is there

Steps to reproduce behavior

touch test
ln -sf test test2

trash put test
trash empty

trash put test2
trash empty

The final command will result in following error

thread 'main' panicked at 'assertion failed: file.exists()', /build/trashy-2.0.0-vendor.tar.gz/trash/src/freedesktop.rs:238:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I would like to integrate this into a terminal file manager. The main use case I have is deleting a bunch of items (with one invocation of trash) and, if I need to, restoring all files deleted by that one command. From reading the help messages for the options, I don't think this is currently possible. Is this possible right now and, if not, could it be implemented?

If you begin trashing a large folder and then interrupt the trashing operation you will be unable to restore the files by merging them back into the partially trashed directory. trashy should just attempt to restore files that do not exist and ask when a file restore operation conflicts with an already existent file.

i have a list of 12 different .py files that i want to put in trash.

is this possible directly?

i tried this command:

trash *.py

& got this error:

error: Error during a trash operation: Unknown { description: "windows error: The parameter is incorrect.\r\n" }

i'm on windows 11 using windows terminal bdw.

sudo timeout -s INT 60 flamegraph --freq 3000 -- trash list:

If I let the command complete (takes more than 3 minutes to list 10 trash item indicies) without interruptions:

If PR #103 is merged, trashy will no longer be compatible with the trash command from trash-cli. I personally support this change because of the shell completion/simplicity it will bring. But that begs the question, why even name the executable trash at that point? It annoyingly conflicts with trash-cli and does not match the name of the project. Why not rename the executable to trashy? It really doesn't make sense for every reimplementation of the freedesktop trash spec to ship an executable with the exact same name.

I recently submitted a PR to nixpkgs to generate and install man pages for trashy, and I ran across the problem of what to name the man page. Should it be trash or trashy? The man page itself is titled trashy(1) and even displays the help string as having an executable named trashy. But of course that is inaccurate; the executable is actually named trash. I ended up creating both trash.1 and trashy.1 man page files and installing both.

Another issue that comes up is tooling that supports trashing files via shelling out to external commands. For example, in Neovim if you want to write a plugin that searches the user's PATH for a freedesktop trash utility, you have to be really careful about figuring out where the user's trash command comes from. In order to support trashy, you have to write something like this:

  trash_cmd = nil
  if vim.fn.executable("trash-put") == 1 then
    trash_cmd = { "trash-put" }
  elseif vim.fn.executable("gio") == 1 then
    trash_cmd = { "gio", "trash" }
  elseif vim.fn.executable("trash") == 1 and string.find(vim.fn.system("trash --version"), "^trashy") then
    trash_cmd = { "trash", "put" }
  end

Seems like all this confusion could be avoided if the name of the executable is changed to trashy. It's unique and matches the name of the project. Perhaps both the PR #103 and this change could be combined into a single breaking change release to make it easier for users to adjust.

trashy 2.0.0

OS Name:                   Microsoft Windows 10 Business
OS Version:                10.0.19045 N/A Build 19045
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free

Color doesn't appear to work on Windows machines.

I was trying to delete my .sqlite database but it was opened by my database viewer.

trash command exited without deleting the file. It should've thrown an error saying the file is locked as its used by another process.

I couldn't find anything about the --ranges flag in the documentation. Though it's a quite helpful flag I reckon.

Hi there, I've been using this program for the last couple of weeks and I've been loving it so far. One of the things I think is missing from rm is a --verbose flag.

I think this flag is super useful for interactive use in the terminal, and I think it would be useful here too. In rm it simply prints the removed files after the fact, like so:

$ touch file file2 file3
$ rm --verbose file*
removed 'file'
removed 'file2'
removed 'file3'

In trashy, I think it could be done similarly, or to maintain consistency with the other subcommands, a confirmation prompt could be used, like how it is already done with the empty subcommand:

$ trash empty file
3 items will be emptied
╭───┬────────────────┬──────────────────────────╮
│ i │ Time           │ Path                     │
├───┼────────────────┼──────────────────────────┤
│ 2 │ now            │ /home/caio/desktop/file  │
│ 1 │ now            │ /home/caio/desktop/file3 │
│ 0 │ now            │ /home/caio/desktop/file2 │
╰───┴────────────────┴──────────────────────────╯
Are you sure? [y/n]

What do you think? Do you think it makes sense adding this flag?
I could help with the development if needed.
Thanks.

Similar to how trash-cli handles restoring items, I would like for the ability to list items within only the current directory from which the command is executed from.

For example, if I am in ~/Downloads, the only items I would like to see from trash restore would be those whose original location was in ~/Downloads.

Using trash restore -d ./ does not work because it no longer prompts for the index of items to restore, but attempts to restore all items.

I've currently forked this repo and removed the check for filters within restore.rs (allowing trash restore -d ./ to still prompt for index) but I'm sure that is not ideal. Willing to consider any better implementations and put in a pull request if that would be helpful.

Example path:

/home/xxx/xxx xxx/aaa bbb ccc.zip

Original scirpt(failed):

trashy list | fzf --multi | awk '{$1=$1;print}' | rev | cut -d ' ' -f1 | rev | xargs trashy restore --match=exact --force

My modified Version(works):

trash list --rev -d . | fzf --multi | awk '{$1=$1;print}' | rev | grep -o '/home.*' | xargs -r -d '\n' trash restore --match=exact

(I don't know whether root user have trash. It may not work for root user)

I just installed trash using cargo, and when I run trash something, I get this error:

error: Error during a `trash` operation: Unknown { description: "Path: '\"/data01/.Trash-1009\"'. Message: Permission denied (os error 13)" }

What does it mean?
/data01/.Trash-1009 desn't exist

i have removed the trash-cli which provides trash-empty command.
i use that trash-empty command in shell scripts to keep up the system maintenance.
trash-empty doesn't ask for confirmation.

how to replace that command with trash command as it keeps asking for confirmation?

Do you have any plans to create an AUR package for trashy?

With the provided fzf integration commands, if you run one, but decide to abort the operation, you have to quit twice. Is there a better solution for this?

Problem
I am writing a script that first checks if the trash list is empty. My current implementation is trying to read the line count with $ trash list | wc -l, but the command incorrectly reports 1 for both an empty trash directory and one with a single item.

Resolution
$ trash list | wc -l should return different results if the directory is empty vs. contains a single item. Whether an empty directory reports 0 or a single directory reports 2, I am fine with either implementation.

Demonstration
$ cd Desktop
$ touch test
$ trash put test
$ trash list

╭───┬──────┬─────────────────────────╮
│ i │ Time │ Path                    │
├───┼──────┼─────────────────────────┤
│ 0 │ now  │ /home/omer/Desktop/test │
╰───┴──────┴─────────────────────────╯

$ trash list | wc -l

1

$ trash empty --all

1 item will be emptied
╭───┬────────────────┬─────────────────────────╮
│ i │ Time           │ Path                    │
├───┼────────────────┼─────────────────────────┤
│ 0 │ 11 seconds ago │ /home/omer/Desktop/test │
╰───┴────────────────┴─────────────────────────╯
Are you sure? yes

$ trash list

╭───┬──────┬──────╮
│ i │ Time │ Path │
╰───┴──────┴──────╯

$ trash list | wc -l

1

I am using zsh with tmux, powerline10k on nixos and whenever I try to tab complete with anything beginning with trash it simply moves the prompt to a new line, this doesn't happen with trash-cli.

I accidentally created some symlinks to images in a mounted drive. I deleted them with trashy put. Unmounted the drive and forgot about it. Now I'm trying to empty the trash but I get the error:

error: Error during a `trash` operation: FileSystem { path: "~/.local/share/Trash/files/IMG_20240310_220717_1.jpg.2", kind: NotConnected }

The file ~/.local/share/Trash/files/IMG_20240310_220717_1.jpg.2 is a symlink to an image in the unmounted drive.

I compiled from source and there hasn't been any changes since, so trashy is up to date (v 2.0.0)

Hi

I used trashy via nix home-manager (23.05 and 23.11 and master) and via cargo install trashy.
In all the dependency to trash is not 3.0.6 but still 2.xx.
Which leads to the crash when removing symlinks.

If you update the version of a dependency I think you should at least also update the minor version of the whole app.
Sticking to 2.0.0 all the time makes it very hard to figure out why my 2.0.0 does not work but if I download it directly from github 2.0.0 works.

In addition a recommended way of installation would be nice. To me it seems downloading from github makes the most sense because using cargo install seems to install an old 2.0.0 version.

Trying to use trash put and trash restore on a mounted volume (mounted on for example /run/media/username/volumename/) seemingly tries to access /run/.Trash-1000 and fails. trash list however works as expected.

Setup

NixOS 24.05.20240323.44d0940 (Uakari) x86_64
nix-channel --list:

• nixos https://nixos.org/channels/nixos-unstable
• nixpkgs https://nixos.org/channels/nixpkgs-unstable

Username: username
Mounted BtrFS volume named volumename

Put file in trash

Steps to reproduce

1. Have an empty trash bin
2. Navigate to the root directory of a mounted volume under /run such as /run/media/username/volumename/
3. nix-shell -p trashy
4. trash list
5. touch test
6. trash put test
7. trash list

Observed

The file test is still present in the directory, and the trash bin is empty. trash list shows no files before or after.

trash put test gives this error:
error: Error during a `trash` operation: Unknown { description: "Path: '\"/run/.Trash-1000\"'. Message: Permission denied (os error 13)" }

Expected

The file test is removed from the directory and is then listed with trash list.

Counterexample

1. Have an empty trash bin
2. Navigate to ~/
3. nix-shell -p trashy
4. trash list
5. touch test
6. trash put test
7. trash list

Observed

The file test is removed from the directory and is then listed with trash list.

Restore file from trash

Steps to reproduce

1. Have an empty trash bin
2. Navigate to the root directory of a mounted volume under /run such as /run/media/username/volumename/
3. touch test
4. Use a file explorer to put test into the trash
5. Confirm that test shows up in the trash bin
6. nix-shell -p trashy
7. trash list
8. trash restore test
9. Type y and Enter
10. trash list

Observed

Both before and after trash restore, the file test shows up under the path /run/, missing the media/username/volumename/ path components. The file remains in the trash bin and does not exist in the current working directory.

trash restore test gives this error:
error: Error during a `trash` operation: Unknown { description: "Path: '\"/run/test\"'. Message: Permission denied (os error 13)" }

Expected

The file test is listed with trash list, then is restored to the current working directory and is no longer listed with trash list. The trash bin is empty.

Counterexample

1. Have an empty trash bin
2. Navigate to ~/
3. touch test
4. Use a file explorer to put test into the trash
5. Confirm that test shows up in the trash bin
6. nix-shell -p trashy
7. trash list
8. trash restore test
9. Type y and Enter
10. trash list

Observed

The file test is listed with trash list, then is restored to the current working directory and is no longer listed with trash list. The trash bin is empty.

pressing <tab> on the trash command only auto-completes for the commands, not the files in the directory. trash put completion works as expected.

i don't know how "clap_complete" works, but you can fix the completion by prepending the line complete -c trash -F to the automatically generated completions.

i only know about fish, but zsh still seems to be broken as of #57.

dropping trash in favor of trash put like suggested in #57 (comment) would obviously work as well, but would be a major breaking change and the loss of a selling point.

I am unable to install trashy on my M1 Mac. Here are the details of my environment:

Environment:

Macbook M1 Pro
macOS 14.4.1 (23E224)
Cargo 1.78.0 (54d8815d0 2024-03-26)

Log

...
Compiling trashy v2.0.0
error[E0433]: failed to resolve: could not find `os_limited` in `trash`
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trashy-2.0.0/src/app/command/empty.rs:52:12
    |
52  |     trash::os_limited::purge_all(items.items())?;
    |            ^^^^^^^^^^ could not find `os_limited` in `trash`
    |
note: found an item that was configured out
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trash-2.1.5/src/lib.rs:295:9
    |
295 | pub mod os_limited {
    |         ^^^^^^^^^^

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trashy-2.0.0/src/app/command/list.rs:94:28
    |
94  |     let mut items = trash::os_limited::list()?;
    |                            ^^^^^^^^^^ could not find `os_limited` in `trash`
    |
note: found an item that was configured out
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trash-2.1.5/src/lib.rs:295:9
    |
295 | pub mod os_limited {
    |         ^^^^^^^^^^

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trashy-2.0.0/src/app/command/list.rs:100:48
    |
100 |     Ok(process_items(rev, max, filters, trash::os_limited::list()?))
    |                                                ^^^^^^^^^^ could not find `os_limited` in `trash`
    |
note: found an item that was configured out
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trash-2.1.5/src/lib.rs:295:9
    |
295 | pub mod os_limited {
    |         ^^^^^^^^^^

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trashy-2.0.0/src/app/command/restore.rs:66:12
    |
66  |     trash::os_limited::restore_all(items.items())?;
    |            ^^^^^^^^^^ could not find `os_limited` in `trash`
    |
note: found an item that was configured out
   --> /Users/[USERNAME]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trash-2.1.5/src/lib.rs:295:9
    |
295 | pub mod os_limited {
    |         ^^^^^^^^^^

For more information about this error, try `rustc --explain E0433`.
error: could not compile `trashy` (bin "trash") due to 4 previous errors
error: failed to compile `trashy v2.0.0`, intermediate artifacts can be found at `/var/folders/vn/nrjpytk92j5br678y6kpr97m0000gn/T/cargo-installVY63jz`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
...

It seems like the os_limited module in the trash crate is not being resolved correctly. Please advise on how to resolve this issue.

issue

i have a drive mounted on /mnt/drive, using trash empty --all correctly shows me the trashed files, but confirming "y" on the prompt panics

running the same command (trash-empty) with trash-cli prompts me to delete the trash from /mnt/drive/.Trash-1000/ and then correctly empties the trash

stacktrace

thread 'main' panicked at 'assertion failed: file.exists()', /home/may/.cargo/registry/src/github.com-1ecc6299db9ec823/trash-2.1.5/src/freedesktop.rs:238:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at 'assertion failed: file.exists()', /home/may/.cargo/registry/src/github.com-1ecc6299db9ec823/trash-2.1.5/src/freedesktop.rs:238:9
stack backtrace:
   0:     0x55aabd23626a - <unknown>
   1:     0x55aabd253e9e - <unknown>
   2:     0x55aabd233465 - <unknown>
   3:     0x55aabd236035 - <unknown>
   4:     0x55aabd2376bf - <unknown>
   5:     0x55aabd2373fb - <unknown>
   6:     0x55aabd237dc9 - <unknown>
   7:     0x55aabd237b22 - <unknown>
   8:     0x55aabd23671c - <unknown>
   9:     0x55aabd237872 - <unknown>
  10:     0x55aabd03da83 - <unknown>
  11:     0x55aabd03db1d - <unknown>
  12:     0x55aabd06a574 - <unknown>
  13:     0x55aabd058361 - <unknown>
  14:     0x55aabd06ac6b - <unknown>
  15:     0x55aabd06aa05 - <unknown>
  16:     0x55aabd05850f - <unknown>
  17:     0x55aabd06b068 - <unknown>
  18:     0x55aabd054a73 - <unknown>
  19:     0x55aabd06fb79 - <unknown>
  20:     0x55aabd22d3ec - <unknown>
  21:     0x55aabd06de15 - <unknown>
  22:     0x7f6104344790 - <unknown>
  23:     0x7f610434484a - __libc_start_main
  24:     0x55aabd03e0b5 - <unknown>
  25:                0x0 - <unknown>

info

$ trash --version
trashy 2.0.0

running on arch, installed via the AUR