what happens on Linux servers without desktop env?

[tessus]

I am wondering what happens on Linux servers that do not have a desktop environment, e.g. Fedora server, Debian server, ...

---

Info for reference:

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.

[Byron]

I recommend adding an example that deletes a file it creates, similar to https://github.com/Byron/trash-rs/blob/master/examples/delete_method.rs , which should then help to see what's happening on your particular platform.

From there it might be possible to create a reproducible issue that one day can be fixed.
Thank you.

[tessus]

@Byron agreed, the unwraps and panic is a different story. But there still should be a sane way to use this lib on a headless server.

I've read the specs again and it basically requires and administrator of a system to create a $topdir/.Trash directory that all users can write too. I still need to look into this, because nobody should be able to read others' trash items. But this spec is not for a system that does not have such a folder or folders (when you are using several filesystems), because a user (who runs a program that uses the lib like dua) does not have the permissions to create anything in $topdir.

It also talkes about XDG_DATA_HOME env var, which obviously won't exist on a headless server (server w/o desktop environment), so the default is assumed: $HOME/.local/share. The user has write access to a subdir in his home, but the Trash directory is not created in $HOME/.local/share nor is $HOME/.local/share/Trash used when it already exists.

So maybe there is a mixup because the home dir is a link to a different filesystem. However, logic dictates that if I delete something from my home dir, the trashed items can still be moved to a directory in my home dir (since it will be on the same filesystem) unless that dir or any subdirectory lower than the $HOMEDIR is a link.
So if .local, .local/share, and .local/share/Trash are not links, it is perfectly valid to use $HOME/.local/share/Trash as a trash folder for any items in $HOME.

P.S.: I did some additional tests, and it looks like the trash-rs lib ignores part of the specification and does not even try to use $topdir/.Trash. As an admin one can create one directory in $topdir ($topdir/.Trash), but not N directories for N users ($topdir/.Trash-1000, $topdir/.Trash-1001, ...).

So what the library has to do is this: create a directory $topdir/.Trash/<userid> with permissions 770. Only if $topdir/.Trash does not exist, it should try to create it with permission 1777 (which will most likely fail, since a user does not usually have permissions to create dirs in $topdir). If that doesn't work, the lib should then try to follow the rest of the spec.
Additionally the library must return the location of the trash directory.

[Byron]

Thanks for your analysis, it's much appreciated!

It does look like there is hope for trash-rs to implement something that works on headless servers as well and by following the spec more closely.

Maybe you can start contributing here despite not being a Rust dev, as there is two low-hanging fruit to be picked. For warm-up, I recommend replacing the .unwraps() with errors. A second stage could be an update to the API that reveals the top-level trash directory that the library will use to move files into. Then dua can find a way to display it which seems like an improvement to the situation, as suggested by you over in the dua-cli repo.

From there the world will already look different and it might be possible to make this crate follow the spec more closely with incremental improvements. I am happy to help if PRs are submitted early as draft.

[tessus]

For warm-up, I recommend replacing the .unwraps() with errors

This might seem a low hanging fruit, but requires actually a bit more info.

e.g. unwrap should never be used, unless a panic condition cannot happen (and would only happen due to a bug in the code). The fact that a certain file/directory does not exist is a likely condition and a proper test must be done. The question now is, whether this is done in the library or in the code that calls the library. In reality it should be both.

However, when replacing the unwrap calls in the lib, it will require a change of the API: e.g. shall an error be returned or shall the return value be an Option<String>. This will most likely have a snowball effect, thus it is not a simple task.

A second stage could be an update to the API that reveals the top-level trash directory that the library will use to move files into

This also needs a specification. There are a bunch of different ways to accomplish that. This is your code, so you should have a preference.

it might be possible to make this crate follow the spec more closely

I thought the entire idea of this crate was to follow the FreeDesktop Trash Spec. However, it seems that the main algorithm was read from bottom to top and only the 2nd part was implemented. While in reality it should first do the 1st part and if this fails the 2nd part (with the option to disable this). Nowhere in the specs does it say that the code should panic.
What is the point of using a lib that only implements part of a spec? In that case, you could have just used a very simple logic:

• for files in home folder, use XDG_DATA_HOME. if env var not set, use $HOME/.local/share/Trash
• for files outside of home folder, use $topdir/.Trash and create users' trash dirs with permissions 770.

I am very sorry, but I do not have the time to look into this. I understand the idea behind such a lib, but in that case it must follow the specs and provide more info to the user of this lib.
In this state it should not have been used in a project, but that's just my opinion.

[Byron]

However, when replacing the unwrap calls in the lib, it will require a change of the API: e.g. shall an error be returned or shall the return value be an Option. This will most likely have a snowball effect, thus it is not a simple task.

It's OK to change the API to indicate errors may happen, so return values might change to Result<_, Error>. My rule is to never use unwrap() or make it expect(<why>) to make clear this is an assertion. Most assertions are broken by a fuzzer or reality though, so not using any of these is never wrong for libraries as this won't ever disturb applications.

If more tests can be added because they are valid and missing, that's great. But there is no need to have a test for every possible error at all.

This also needs a specification. There are a bunch of different ways to accomplish that. This is your code, so you should have a preference.

I am not the original author and am merely maintaining the crate. I am not much of a planner and rather see a draft PR develop than talk about things without reference to any code. As it's a possible second stage, I don't think there is any reason to dig into this further at this time though.

I am very sorry, but I do not have the time to look into this. I understand the idea behind such a lib, but in that case it must follow the specs and provide more info to the user of this lib.
In this state it should not have been used in a project, but that's just my opinion.

Maybe this conversation will help others with time to leverage the analysis done here bring this crate to the next level. Thanks for your involvement, and sorry to see you go.

[tessus]

I might be able to work on this in the future, but if I were the maintainer/author of that crate, I could do the changes I was talking about in less than 30 minutes.

For me it would take quite some time to understand the entire code base and then I'd also have to deal with Rust, which I never really used before (except for one PR in vaultwarden). I estimate roughly 48 hours in total. So comparing the 30 minutes to 48h is a no brainer and I am not going to invest that time. Should I ever become a Rust guru, I'll come back and create a few PRs. Until then, I hope somebody will find 30 minutes to get these changes in. ;-)

[ArturKovacs]

I suggest trying how gio behaves in the scenario you layed out. gio also implements this specification, so copying its behaviour could be a solution

[tessus]

I am rather new to Rust and I wouldnt call myself a Rust dev, thus I am not sure whether I am up for the task.