[File Explorer] Feature Suggestion: Instant & atomic non-permanent deletion of directories (to Recycle Bin) by first moving to temp

[scscgit]

Description of the new feature / enhancement

It's difficult to delete large (and deeply nested) directories, for example caches of package managers (e.g. node_modules of npm), using Explorer directly, because you need to wait for the entire operation to complete before you can reuse the same filename. There are also common issues like some filenames making the path too long for Explorer, any file access/lock issues (when the move works but deletion doesn't, i.e. sometimes we have to wait or kill the process, other times the file can be removed on startup). In addition to wanting this action to be fast, sometimes we prefer not to remove the files permanently in order to keep the option of recovering the files.

Interestingly, one of the fastest solutions how to "get rid of the files" is to move the directory instead of deleting it directly. This also doesn't require us to make the decision to permanently remove the files (without going to the Recycle Bin). My suggestion is to use a similar or better technique, using any temp directory to hold the remaining files until they are deleted (moved to Recycle Bin), so that the existing file path is empty as soon as possible and user can re-use it. This would also enable atomic deletion, removing risks of anything new being added to the directory during its removal. It could be effectively a script that's executed instead of the action of deletion to Recycle Bin, making it transparent to the user, but it'd need to integrate with the existing "Deleting" UI in Explorer, so this scope depends on what's reasonable for PowerToys to implement (this could be also implemented in Explorer after all, but it likely won't be). Because this is a power tool configuration, the edge case scenarios like cancellation in the middle of the process, access failures after the directory has been moved, or the cleanup of files after failure (including OS crash) likely don't need to be perfect, but they should be consistent from user's perspective, and especially not done as a black-box. For example, if the temporary recycle bin cache is a well-known location, PowerToys could notify (on startup?) about any unfinished operations and let us choose the course of action.

I don't know about a direct way to move files to Recycle Bin using command line, but there seem to be some solutions based on:

• https://superuser.com/questions/24662/what-is-the-command-line-way-of-sending-files-to-the-recycle-bin

However, as the deletion would be performed from a different location, the Original Location in Recycle Bin must be changed to point towards the correct place (not to a temp directory) to make the user experience safe and consistent. The Explorer actions of Undo/Redo thus also need to be supported (preferably with their safety improvement #16337) (though Redo could optionally use the old slow deletion behavior), consistency being the primary advantage over random scripts.

---

There are also various third party solutions for deleting large files more efficiently without going through Recycle Bin, for example rimraf. It'd be great if we also agreed on one such solution for power users (consensus on anything open-source?) that PowerToys could officially support and integrate with Explorer (e.g. to be used on Shift+Delete?). This fast permanent deletion is tracked at #1643.

Scenario when this would be used?

We're often dealing with large directories, especially as software developers when using third party tools that bloat our hard drive.

We usually prefer to prioritize our productivity by making actions like deletion instant whenever possible.

If there are popular workarounds out there, it's preferable to have them standardized and integrated with shell in a way where trash can keep going to Recycle Bin, rather than having us come up with ad-hoc scripts, installing random third party apps, or manually creating dozens of temporary directories that we have to keep in mind for cleanup at later time.

Supporting information

• https://spblog.net/post/2020/06/10/how-to-effectively-delete-node-modules-on-windows
• https://stackoverflow.com/questions/186737/whats-the-fastest-way-to-delete-a-large-folder-in-windows
• https://www.quora.com/Whats-better-Moving-items-Or-copying-them-then-deleting-the-old-one
  • "Within a filesystem, when you move an item, you are just changing the name of it. No data bits on disk are moved at all."
• https://stackoverflow.com/questions/28175200/how-to-delete-node-modules-deep-nested-folder-in-windows

[Jay-o-Way]

What about (either manually or via script) changing the name of the first large folder? then you'd have all the time to delete it, possibly in the background.
Programs like CCleaner also have the option to delete specific folders. Might not be as instant as you want it to be, though, but maybe if there are a number of them?

Also, by the book I should mark this as a duplicate of #1643, where a number of people have tried to do this - it has a simple line of code that seems to work well. But I don't just wanna close out all the info you gathered here 🙃

[scscgit]

@Jay-o-Way Renaming the folder is pretty much the same as moving it, but the key here is that it should be no longer available near the original location during the deletion. The most common example would be using a Git version control over a project, in which case any "renamed folder" will conflict with .gitignore and further with actions like reset / checkout. On the other hand, when you manage personal data, your intention would be not to forget to clean the directory even if the process crashes and you forget to complete the workflow, leaving your data in inconsistent state with redundant files. The current state of process must be intuitively tracked so that you can keep it out of your mind, e.g. imagine deleting 10 directories at once, and then having your drive disconnect or files being locked.

Unlike #1643, this feature is explicitly concerned with moving the data to Recycle Bin, because that's the Windows-specific default behavior that users expect when they want to keep the option of recovery from any mistake (even after a long time), and it's way more difficult (if not impossible) to automate from command line. The case of "deleting large files more efficiently without going through Recycle Bin" can be surely tracked in the existing issue.

[crutkas]

To me, you are asking for fast delete at the end of the day. Anything temp folder gets dangerous for it existing in a long term also. This is implementation details that go beyond the core issue of delete is too slow unless I’m missing something.

I would dup this against #1643. /needinfo

[scscgit]

I've re-phrased the scope of this feature to be specifically related to non-permanent deletion, so that #1643 can be explicitly focused on the permanent one. (From users' perspective, this is the difference between default behavior of Delete vs. Shift+Delete). We can surely merge the issues if the other one includes this as part of its scope, because for now it merely suggests del command.

And about the "dangers" of a temp folder, I'd like to see any points being discussed against this process of "move" (effectively rename in filesystem) being an objectively superior choice compared to waiting for enumeration of all files before starting a long non-atomic process, which even leaves behind inconsistent state if it ever crashes.

• That is, at least so far as when the target drive of temp directory is the same one. Maybe the temp location will be tricky to make consistent when dealing with external drives, because the move to system drive obviously wouldn't be instant anymore. Windows already uses a dedicated hidden location for Recycle Bin even for external drives, so here I'd wish to hear suggestions from experts on its inner workings in case we're able to find something along the lines of "temp hidden inside Recycle Bin", or if there is alternatively a way to also recycle by moving.

As I view it, the risks are primarily that of users forgetting to clean up the temp folder after any crash, however, this is supposed to be a power user tool, meaning we enable it intentionally and are aware of the location of this temp folder, visibly being displayed along with the size of its content (unlike the trillions of applications in %userprofile% or %appdata%, especially the \Cache of any electron app that never gets cleaned up because these developers are just evil). By trying to avoid this silly idea of a black-box behavior, Power Toys could instead focus on transparency since the first moment we enable this feature (it doesn't even need to be enabled by default), and as I previously mentioned, it could be stateful, thus displaying any unfinished process whenever the app gets restarted and the temp isn't empty. Thus the only risk is of us intentionally installing this app, starting a large delete process, crashing OS, and then deleting the app without ever running it again (without even going through uninstaller).

Additionally, this move to temp can be used in combination with the optimization of permanent deletion in #1643, making it both instant and also faster to complete in background.

(Another funny detail/bug to illustrate how we're slowly losing the sane defaults which I'd like to improve rather than give up: if the entire Recycle Bin is manually turned off, Shift+Delete doesn't display any confirmation dialog regardless of this dialog being enabled or disabled: https://superuser.com/a/1705032)

[crutkas]

Lets step away from implementation. How / where stuff goes is a solution.

• Is the problem moving files to the recycling bin is too slow, correct? Doing instant delete is too aggressive for you from Fast Delete #1643, correct

[crutkas]

/needinfo

[scscgit]

Yes, moving to recycle bin isn't instant and isn't atomically safe. Permanent deletion of files is unacceptable by default, except for very specific scenarios where we are 100% certain there is no risk of data loss and we already have redundant backups. (There's a UX reason why default Delete behavior isn't irrecoverable, and the reason doesn't disappear for us just because we are software developers.)

We can also analyze whether "move to temp can be used in combination with permanent deletion", because the "Fast Delete" solution still isn't instant despite filesystem supporting this (by first moving/renaming the root directory).

[crutkas]

/feedbackhub

[ghost]

Hi! We've identified this issue that best is suited for Windows Feedback Hub. To do this on Windows, WinKey+F will bring it up!