Ctrl+t does not move files to trash

[tessus]

I just installed dua-cli 2.19.2 via cargo install and deleted a few files via dua i and Ctrl+t.

Those were test files/directories, so I don't really care, but they were not moved into the trash folder, but deleted right away without a warning. Unless the trash bin is no longer ~/.local/share/Trash.

I am on a Linux server without desktop environment.

Any ideas what might be happening?

[Byron]

This operation is performed by the trash crate, which is dependent on the platform. It doesn't necessarily work on any platform even though it's strange it claims to work and then doesn't.

It's best to further debug the issue there though.

[tessus]

ok, I'll add above info to the discussion in the trash-rs repo.

[tessus]

although I think this issue should be tracked here as well. My sytem is nothing fancy. Just a Fedora Server edition without desktop environment. It is rather concerning and IMO a critical bug, since it deletes data without a warning. This should have a high priority.

[Byron]

It doesn't delete anything, but moves files. If the move worked there is no error. However, if the directory it decided to move it to doesn't match what's expected, it might seem like files have been deleted even though they are still present. trash-rs is where possible fixes need to be applied, hence the issue is tracked there.

[tessus]

You are right, but the frontend (dua) should tell the user where the trash directory is. This might need changes in the trash-rs code, but dua should still show it.
What are people supposed to do? Search potentially billions of directories/files for a trash directory, which people do not even know the name of?

[Byron]

That would be a possible improvement once it's clear that trash-rs cannot be assumed to work correctly everywhere.

Edit: cargo build --no-default-features --features tui-crossplatform --release will build dua without trash-rs support.