-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
Add a setting to bypass recycle bin or detect if recycle bin is supported #14638
Comments
A setting might be the worse user experience. Maybe we could detect if the recycle bin is supported before trying to use it. This would require API in Electron though. As a workaround we added support in 1.6.x release to bypass the trash if you press and hold the shift key while invoking the delete. See #9354 |
@bpasero Great. Anyway if it could be solved will be okay. ^_^ |
I would add, that I personally view the recycle bin to be an OS feature, not something dependent on the type of drive where I delete (btw - why don't e.g. USB stics or remote drives "support" recycling?). Anyway, I see these options:
|
Hi As mentioned here #329 (comment) some times ago, there is another issue with moving to recycle bin when you use code in a portable way (ie with custom settings and extensions dir). So a CLI option to disable recycle bin entirely, even if OS provides support for recycling still does make sense IMHO Cheers |
The behavior described in this issue also repros if the recycling bin is outright disabled. This was previously reported in #1646, but that issue was considered a dupe and was closed. However, it seems either this behavior has regressed or #1646 wasn't actually a dupe as I'm hitting this issue with a 100% repro rate. My setup:
Now to inject my opinion, I would absolutely expect any app running on Windows to respect the configuration of the underlying OS. I'm not sure what the reasoning is for VSCode to have special handling for the actual deletion of files and why it can't let the OS handle it, but overriding the file system to force an unsupported condition makes for an awkward situation. Admittedly, this particular bug is very small and the workarounds are quick, but the little annoyances add up and I'd prefer not to fight muscle memory to use a different key combo every time I want to delete a file. If this is something that isn't considered high enough priority to be fixed in the near future, then I would be very much in favor of a setting to toggle the recycling bin off. From a user experience perspective, it may still be a workaround but it's a workaround I would only have to apply once and therefore I would consider this to be a preferable workaround compared to using shift-delete. |
this happens 100% of the time when using a remote file system such as NFS. |
The experience with upcoming 1.21 release is nicer, I think a setting is actually not needed. Just set Just hit enter and the file should be gone. I am not feeling too good about a solution where VS Code would delete something permanently without asking, so I think this solution with one prompt is better compared to before where you had to click the notification message action using the mouse. |
I can't speak for others and I suspect I'm not in a majority, but I feel like a setting for that would be warranted regardless of whether the recycle bin exists (or is enabled) or not. I just want to permanently delete by default, without disabling the recycle bin system-wide. It's bad enough (for me) that the OS by default moves to the recycle bin on delete and I have to shift+delete every time, I would like to at least be able to configure the editor I use to fit my needs. Even if it's not the default option, because, like I said, I suspect I'm in the minority here. But this should be easy enough to set up that I can't see a reason not to do it. |
Verification: There is now a setting
|
Steps to Reproduce:
Suggest:
Add an option
disableRecycleBin
in file.vscode/settings.json
, so that we can tell the VSCode not to use recyclebin for a specific project/folder.The text was updated successfully, but these errors were encountered: