Use XDG_DATA_HOME environment variable if the variable is set and no other options like GRAVEYARD or '--graveyard=' were specified. In such case use "$XDG_DATA_HOME/graveyard" as graveyard. Since XDG_* variables are user-specific, there is no reason to append username to the name of graveyard folder.

When removing a symbolic link pointing to a directory, I expect rip to behave like rm which remove the symbolic link itself. However, rip removes the physical directory instead.

Fantastic tool! Works great overall, just one minor quibble: XDG_DATA_HOME seems to not work.

Linux 4.15.0-50-generic #54-Ubuntu x86_64 GNU/Linux
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

rip 0.12.0

I have XDG_DATA_HOME set to /home/mike/.local/share. Rip is still sending files to /tmp/graveyard-mike.

Thanks!

$ rustc +nightly --version
rustc 1.32.0-nightly (14997d56a 2018-12-05)
$ cargo +nightly install rm-improved
    Updating crates.io index
  Installing rm-improved v0.11.4
   Compiling libc v0.2.45
   ...more "Compiling" lines
   Compiling error-chain v0.8.1
   Compiling rm-improved v0.11.4
error[E0463]: can't find crate for `alloc_system`
 --> /home/paul/.cargo/registry/src/github.com-1ecc6299db9ec823/rm-improved-0.11.4/src/main.rs:5:1
  |
5 | extern crate alloc_system;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: failed to compile `rm-improved v0.11.4`, intermediate artifacts can be found at `/tmp/cargo-installVQRbyH`

Caused by:
  Could not compile `rm-improved`.

To learn more, run the command again with --verbose.

In rip's current state, a normal user could (depending on kernel settings) trick arbitrary users into overwriting arbitrary files (either on delete or restore).

You need to make separate graveyards per-user and rip needs to make sure that each user graveyard is owned and writable by the user and only by the user. Alternatively, you could use setuid and run rip as root (and do some very careful permission checks) but that's very hard to do correctly. You could also run a rip daemon as root but that would complicate things.

Resolves #14. ~~This is conditional based on https://github.com/Homebrew/homebrew-core/pull/64107/ merging, so I am leaving it as a draft until then.~~ rm-improved is now available via Homebrew.

Build was broken because the uninstall path was wrong. Simpler option is just not to have Rust installed at all by using the generic image :) I've also upgraded the travis config to more modern options.

Hi, I've added this package to AUR as rm-improved (due to name conflict with rip). Feel free to include installation instruction in your README.

Something like this:

ArchLinux installation:

Package can be installed from AUR. $ yay -S rm-improved

What if /tmp is a partition with size x and you delete an file with size y and y > x? What if /tmp would be big enough for y, but only free space of size m is left and m < y?

~/.trash seems to be more appropriate.

The current behavior is to loudly fail when =rip= encounters a non-regular file, like those produced by =mkfifo= or =mknod=. Is there a safe and consistent way to deal with these?

Since the graveyard is stored in a globally accessible directory by default, all users get their files sent to the same directory. If rip -r as a normal user tries to restore something deleted from /root, it will throw an error.

The proposed solution is to include the username in the histfile and limit rip -r to files owned by $USER. The current histfile structure is not flexible enough to support this, so it's probably best to make it an append-only log and implement a parsing algorithm (with stacks and such) for the resurrect option. The downsides are worse performance and disk usage, but these should be totally negligible.

If a file was deleted, and an item with a parent that has the same path of that file was also deleted, rip fail to delete the file.

E.g., assuming graveyard is /trash and current folder is /:

$ touch item
$ rip item
$ mkdir item
$ touch item/file
$ rip item/file
error: Failed to bury file
caused by: Failed to move /item/file to /trash/item/file
caused by: Not a directory (os error 20)

rip will try to move file to /trash/item/file, but does not check if /trash/item exists and is a file.

error: Failed to write record at /Users/leontepe/.Trash/.record
caused by: Operation not permitted (os error 1)

System: macOS $GRAVEYARD: ~/.Trash

It still deletes the file though—as in it's not present in the original location anymore after running the command.

It is not really an issue, so should be ok to close it. Just wanted to share my excitement in discovering this tool, as it looks perfect for my need to stash files.

While working for eg. in a git repository or elsewhere, I end up creating some temporary files which doesn't really belong in the repository. At the same time, I don't feel like deleting them permanently as there is a chance I might need them sometime in distant future. But if I don't remove them the list of Untracked Files in git keeps increasing.

So, I have added alias stash="rip --graveyard <my homedir>/stash". Rip will take care of keeping the backup, keeping multiple backups in case of conflicts and retaining the whole path. As a bonus, stash -s lets me see files stashed in current directory. So, thank you for this tool :)

Suppose I use rip to move a large directory of files which takes a long time to finish. What happens if rip is interrupt before it finishes. Will any file be moved or will it leave nothing changed?