Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trash dir #60

Closed
lunacookies opened this issue Nov 5, 2019 · 6 comments
Closed

Trash dir #60

lunacookies opened this issue Nov 5, 2019 · 6 comments

Comments

@lunacookies
Copy link

Hi,

I was recently looking for a way to locate the user’s trash directory and noticed that some issues here mentioned trash, but that this didn’t seem to be present in this library. However, it seems that trash_dir is still in lib.rs, just that it is commented out. Assuming that this was once provided by this library, would it be possible to restore this feature?

Thanks.

@soc
Copy link
Collaborator

soc commented Nov 5, 2019

Hi Aramis,

the problem is that Windows' trash folder doesn't have a "real" path that we can return to the user, see: #18

As there doesn't seem to be a consistent way to return this directory on all supported platforms (and there is usually not a per-user trash directory, but a per-disk one), the decision was made to not offer this API here.

@lunacookies
Copy link
Author

Since this library returns Optionss of values, couldn’t you return None on those platforms that don’t support locating trash? Or is it that all supported platforms don’t support locating trash.

AFAIK and FWIW trash on macOS is always $HOME/.Trash, and on (some?) Linux distros it’s $XDG_DATA_DIR/Trash. This is just from a quick Google and you’ve probably done way more research than me on this though.

@soc
Copy link
Collaborator

soc commented Nov 6, 2019

My concern is that it would confuse the reasons why one might get a None.

Without trash, it's basically "this OS does not have this dir"; if we added trash, it would add "the OS might have this dir, but we can't give you a path to it" as a second reason to return None.

@lunacookies
Copy link
Author

Ah, I see now. Thanks. Should I close this issue?

@soc
Copy link
Collaborator

soc commented Nov 7, 2019

I'd propose we keep this open for a week and figure out whether we can collect additional pros/cons; after that I'll make a decision based on hopefully more information. :-)

@lunacookies
Copy link
Author

Sounds good 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants