I just fixed the problem, thanks for pointing it out! :D

It's my first project in rust, I didn't really know how to go about getting the most practical installation possible. But thanks for the feedback, I'll work to make the process easier.

Not sure about rust stuff, but trash-cli is simply just packaged for all the commonly used distros.

https://repology.org/project/trash-cli/versions

When a person delete an item, I get all the information that are interesting for me (https://github.com/AmineZouitine/rmt.rs/blob/main/src/trash_...), and then I move it in a .trash folder in which I rename it with a hash (the hash is made with several parameters to avoid any collision), I then store the information in a database sqlite :)

Thanks ! I have many ideas to make the project much more interesting, including adding automatic flush (that the user will have configured), the ability to compress the file before entering the trash etc ... Do you have any ideas in mind?

So glad you asked!

The main one is that files sent to trash are encrypted. So that a private key is required to restore them.

Ideally even the meta data is encrypted.

I've watched too many kids spy movies from the 2010s with files restored from trash!

Edit: just wanted to add I just mean via GPG! Rather than asking encryption be added to the application.

This is a great idea! I hadn't thought about it. I'm currently fixing the major bugs and refactoring the code a bit, and when I finish that, I'll get to your idea, I find it really interesting.

I followed your advice and fixed the problems, I updated the readme and the deployment of the new version (0.1.2) should arrive in 1 hour.

I thank you for raising these points.

I'm fixing the bugs after the feedback and then I'm fixing the Windows problem, I'm using a crate that is not cross-platform for the input management

This was my initial idea but unfortunately there can be name conflicts, if two files or folders have the same name, this idea does not work anymore. Also, I wanted to be able to keep the initial path to restore the element directly where it was deleted.

This was my initial idea but unfortunately there can be name conflicts, if two files or folders have the same name, this idea does not work anymore. Also, I wanted to be able to keep the initial path to restore the element directly where it was deleted.

Hi, thanks for your comment! I fix a lot of things with the numerous feedbacks, and I have a lot of ideas to make the project really interesting and different from what we can find :D

Thank you for your comment, I try to get as close as possible to the signature of the real rm command in order to facilitate aliasing, plus I have many ideas to improve my project that are not necessarily available on rip

I would write to the author of `rip` and ask if you can take the project (including the memorable/cool name) over.

`rip` seems unmaintained (three open PRs from one to five years old). It has a name that doesn't clash with an existing *nix command and people seem to also ask for the same thing since its inception (see issue #3 from 2016).