It's rm with a trash can that by default is in a terribly insecure location (/tmp is typically world read/writable).<p>EDIT: just tested it, it creates /tmp/graveyard-$USER with 0755.
Warning, this software<p>> does not implement the xdg-trash spec or attempt to achieve the same goals<p>Second warning, deleted files become world readable by design<p>> Deleted files get sent to the graveyard (typically /tmp/graveyard-$USER
It's always laudable when OSS projects get some love, but... I'm slightly put off by programs that try to be witty or funny (e.g. flags like --decompose and --seance)
I don't think this is solving the problem at the right abstraction level.<p>For example, you can also "delete" files by accidentally redirecting to them using the ">" operator in the shell.<p>Maybe some kind of snapshotting filesystem (+ tools) is a better way to deal with this.
I wonder what amount of this being pushed so much is<p>- the allure of improving on well established UNIX commands (always an interesting topic)<p>- and the "it's rust factor"
I'm building a general-purpose undo that will log and let you undo things like chmods, chown/chgrps, mv's and rm's. it will work with the recursive parameters of those utilities and shunt that out to `find` with `-exec` so it can track the undo of every individual file. it will use the xdg-trash spec for rm'ing files. I haven't pushed it up to github yet but I have test cases working locally. in particular it will handle idempotent updates properly so if you for example chown a file with the same user and group, it will be recorded as a no-op so that a later (untracked) change won't get overwritten when you undo a tracked change that would otherwise interfere with it.<p>it's just plain old bash, so nothing fancy like Rust, but it should work
A small psa if you're on Windows and like this tool want to focus on "ergonomics" and "performance" of deleting files, disabling real-time protection in the security center makes deleting large directory trees about 50% faster and reduces CPU usage by about 80% for me. It's wholly non-obvious to me why this is the case, considering that DeleteFile doesn't even use a file handle. Perhaps it acquires one internally, and that still triggers demand scanning of the file to be deleted?
I really liked the idea.<p>Played around with rip2 on my MacOS.<p>Unfortunately after playing with it for two minutes, the "undo" and "scance" functionality seemed to break:<p>I have opened a bug <a href="https://github.com/MilesCranmer/rip2/issues/54">https://github.com/MilesCranmer/rip2/issues/54</a>].<p>am I doing something wrong?