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

Trashing a file on Windows deletes it unrecoverably if no recycle bin is enabled #107

Open
mifi opened this issue Dec 11, 2020 · 5 comments

Comments

@mifi
Copy link
Sponsor

mifi commented Dec 11, 2020

Similar to #56, but probably has to be solved in a different way for Windows.
This was reported by a user in my app losslesscut mifi/lossless-cut#537
When he trashed a file on a network mounted drive (which has no trash), the file just got removed permanently.

@sindresorhus
Copy link
Owner

What do you think should happen? Throw an error in such case? Add an option for what to do?

@mifi
Copy link
Sponsor Author

mifi commented Dec 12, 2020

IMO it should ideally throw an error when it cannot trash the file, because the reason why I use this library, is so that the user doesn't lose their file immediately. If trash permanently deletes a file, then IMO it did not do its job. But maybe it's not possible to make sure that it never permanently deletes a file.

@sindresorhus
Copy link
Owner

I agree. It should be a custom Error subclass though, so consumers can easily catch it and decide what to do.

Continued in sindresorhus/recycle-bin#8.

@aminya
Copy link

aminya commented Dec 28, 2020

I want to use this package as a fallback for Electron's shell.moveItemToTrash, but it seems Trash removes the files permanently if it fails to trash them.

The electron function is able to detect the errors somehow avoid the deletion.

Edit: They have switched to shell.trashItem recently for the unreleased Electron 13

electron/electron#26723

@tomasklaen
Copy link

IMO it should ideally throw an error when it cannot trash the file, because the reason why I use this library, is so that the user doesn't lose their file immediately.

I see the reasoning here, but it conflicts with a use case where Windows user can configure their Recycle bin to delete files immediately. In this scenario deleting files instead of moving them to trash is what the user wants, and throwing errors here would be wrong.

So unless you can check that file is being deleted from a drive that doesn't have immediate deletion enabled, you shouldn't throw errors.

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

No branches or pull requests

4 participants