Repository navigation
First use wrong perms in graveyard? #129
Description
Activity
Interesting. Can you give more details on this?
It appears to me that rip can't put the rip'd file in the graveyard because the top directory in the graveyard is not writeable when created.
Let me know if I can provide any other information.
I installed rip2 using
cargo install rip2openSUSE Tumbleweed
Linux hostname 6.17.7-1-default #1 SMP PREEMPT_DYNAMIC Sun Nov 2 16:18:06 UTC 2025 (5d304cd) x86_64 x86_64 x86_64 GNU/Linuxrip --version rip 0.9.5rm -rf /.local/share/graveyardrip somefile Exception: Failed to bury filels ~/.local/share/graveyard dr-xr-xr-x 2 username users 4096 Nov 19 16:33 homechmod 755 ~/.local/share/graveyard/homels ~/.local/share/graveyard drwxr-xr-x 2 username users 4096 Nov 19 16:33 homerip somefilerip -s deletion_time path 2025-11-19T16:40:02 /home/username/.local/share/graveyard/home/username/somefilerip -u Returned /home/username/.local/share/graveyard/home/username/somefile to /home/username/somefileI also have an installation of EndeavourOS (Arch based).
rip2 works out of the box
My environment at the EndeavourOS machine did not have XDG_DATA_HOME set. The graveyard in /tmp worked as advertised.
When I set XDG_DATA_HOME to ~/.local/share/graveyard on the same machine rip2 also worked well.On Tumbleweed:
Running rip with XDG_DATA_HOME unset:rip somefile Exception: Permission denied (os error 13)I was having the same issue. Also on OpenSUSE Tumbleweed. I worked around it by running "chmod 755" on the graveyard_user/home/ directory. It actually used to work for me, but at some point it broke. Not sure specifically when.
Interesting. Well the latest release tries to be better about propagating permissions into the graveyard so when you unbury a file, it has the same permissions, as well as the folder (if they were removed too). Basically it's so that if you rip your ~/.ssh folder or whatever, and then unbury a specific key, the ~/.ssh folder gets rebuilt with the same strict permissions.
But seems like there's some behavioral paths that are hitting issues, clearly.
I wonder if it's something like the root directory on some machines has weird permissions, and so when making the graveyard for the first time, those permissions propagate
- added 2 commits that reference this issue
on Dec 18, 2025
When deleting first file from my home folder it fails, but creates
~/.local/share/graveyard
and in the graveyard I find a home folder created with these perms:
dr-xr-xr-x
When I
chmod 755 ~/.local/share/graveyard/home, then rip works.