Unless you are extraordinarily low on disk space, you should never need to "wait" to delete things so speed shouldn't matter.<p>The correct method is to immediately move/rename the target, then launch an expensive delete in the background. That frees up the location you are trying to use.<p>I used to see people set up entire workflows that started with, essentially, "wait 20 minutes to finish recursively deleting the previous data" instead of just "move it out of the way and start immediately".
Wasn't at some distant time in the past deleting done by just renaming a file and changing the first character to a question mark? I think that also applied to folders: Delete a folder's "file", and all the contents are gone, recursively. Not sure how they found free blocks when creating a file though. One downside is that you never knew how much space you had left. I think at some point they changed it so that all file operations updated the "free space left" label in the partition. This may have been FAT around Win98, but maybe I'm misremembering or it may be some more obscure file system I'm thinking of...
If you're doing this regularly, a good alternative is to install on a separate partition and symlink it. Then to delete, you just quick format the partition.<p><pre><code> echo Y | format Z: /FS:NTFS /X /Q
</code></pre>
source: <a href="https://superuser.com/a/352321" rel="nofollow">https://superuser.com/a/352321</a><p>Also, on Windows 10 you can use Ubuntu bash and run rm -rf. I've read that it's faster, but haven't tested extensively.<p><i>Update</i>: I did a quick test with 100,000 files and the 'del /f/s/q foldername > nul' approach was about 50% faster than 'rm -rf' on my machine.
He's not handling spaces in directory names in the "cd %1" portion of his context-menu entry. Fortunately his "fastdel.bat" should prompt the user and, hopefully, they'll catch the mistake.<p>Calling CMD.EXE from Explorer without double-quoting can have unintended consequences when ampersands and parentheses are present in the filename too. I'd hate to "Fast Delete" a directory named "& rd /s /q %SystemRoot% &" using his shell context menu entry.<p>If I was hell-bent on doing this I'd probably add it to my user registry w/ the command:<p><pre><code> reg add "HKEY_CURRENT_USER\Software\Classes\Directory\shell\Fast Delete\command" /d "cmd /c rd /s ""%1"""
</code></pre>
There's still probably some fun metacharacter injection possibilities there, too, however.
Unfortunately, RMDIR as well as other windows commands suffer from the long path issue. You can turn on long path name support in win10 but that did break our regular build tooling.<p>My current way to delete any folder regardless depth of the tree is to use robocopy (robocopy D:\EmptyFolder D:\FolderToDelete /MIR). It is actually pretty damn fast, might be faster than using RMDIR /S /Q.
This whole page is making me claustrophobic with visions of so many things that can go wrong for trying to optimize the folder delete... Compounded by a helpful samaritan who is offering an EXE download to set up a batch file... :(
Reading this article reminds me how tedious it is to customise Windows. All these manual steps in system dialogs, registry and so on have to be repeated every time you want to re-install Windows.<p>I wanted to run a command as admin on startup recently and had to create a scheduled task for this, which of course will be lost the next time I reinstall. Same for services, etc.
I haven't used Windows seriously for a while, but I'm pretty sure you can use filenames without extensions now.<p>Doesn't that mean that the "<i>.</i>" pattern won't match everything?
Note that these solutions will bypass the trashcan, which is why they shouldn't really be used willy-nilly.<p>They will also trip up in the same way Explorer does, on paths that are too long.
Does anyone know how PowerShell compares to cmd.exe for this particular problem? In PowerShell, one would type:<p><pre><code> rm -Recurse -Force $path
</code></pre>
It has the advantage that it only takes a single command, but I am not entirely certain about the performance.