Nuking files, and tons of 'em, and eliminating the "Discovering" processing. Is it possible.

[britechguy]

I may be getting old, but I don't think I've got the proverbial rose-colored glasses on regarding this. It seems to me that under Windows, up at least until Windows 7, and possibly in Windows 7, you could select folders with massive numbers of files and subfolders contained therein, choose to delete them, and *POOF*, they were gone. There was none of this "Discovering" stuff followed by a slow, item-by-item delete process with a progress bar. The entire structure was effectively, lopped off and every block marked as available.

My web search skill is not turning up anything that seems to work that way now. Using the SHIFT + Delete shortcut when you have a folder selected does bypass the Recycle Bin (which I also want) but it does not eliminate the crawling of the entire folder structure both prior to and during deleting.

In cases like this, I have no interest in knowing how many files are involved or how much space will be freed prior to the deletion.

Is there a "quick and dirty" delete function that can still be used? There's got to be, but if there is I haven't had need to use it in years, and now I do.

 

[HCHTech]

Probably faster with the command line. Sorry that's all I got.

 

[britechguy]

Probably faster with the command line.

Agreed. I'm just wondering if there's a way for those not CLI conversant to do this.

 

[timeshifter]

rd /s /q foldername

 

[britechguy]

rd /s /q foldername

I did this, but sans /q. I'll try that the next time.

This is faster than within File Explorer without that switch, but it may be faster with it.

 

[timeshifter]

Off the top of my head, I think the q stands for quiet.

 

[HCHTech]

Off the top of my head, I think the q stands for quiet.

Yes, /q = no "are you sure?" prompts. Also, be damned careful when using this!

 

[britechguy]

Just to be very, very clear here, when I'm going about nuking I am absolutely certain that the thing about to be nuked can go.

 

[SAFCasper]

Don't know the science behind it but faster to delete files first, followed by the remaining empty directories.

del /f /s /q C:\Folder\to\delete > nul
rmdir /s /q C:\Folder\to\delete

Not a huge difference if you are deleting 10's of thousands. Becomes quite significant in the 100's of thousands or more.

 

[HCHTech]

I did a bit of searching this morning, and folks have been complaining about this since Vista. No consensus on a workaround, and considering the time that has passed, it's not on MS's roadmap to address it.

 

[britechguy]

folks have been complaining about this since Vista

Well, at least it gives me comfort to know:

1. That others hate this, too.
2. That there was a time, clearly pre-Vista, where a delete was, for all practical intents and purposes, instantaneous.

With the advent of the Recycle Bin, I tend to care far less than I once would have about accidental deletions. And I haven't had any accidental deletion for as long as I can remember now.

 

[Larry Sabo]

Give LPE (Long Path Eraser Free) a try. It has worked wonders for me when trying to erase user data back-ups on my storage drives and there are file system errors.

 

[britechguy]

@Larry Sabo

Thanks. When this situation next presents itself, and it will, I'll give that a whirl.

 

[NviGate Systems]

Some WindowsPE versions have modded Explorer to partially solve this drama.

In relation.....

 

[Mick]

In my folder of might-be-useful-one-day powerscript commands/dodges/hacks, I have this:
Remove-Item c:\yourhugefolder\delete -Force -Recurse
Caveat: I do not personally recollect ever using this in anger.

 

[fincoder]

Regarding that video, the question that comes to mind is: when copying only one big file why is the "calculating..." displayed for so long and not just a simple mathematical calculation based on the first few kilobytes transferred? Caching etc might slow down the transfer slightly later on, but the accuracy would be quite good. CPUs are so fast now that some extra logic in the progress dialog would have minimal overhead compared to the massive overhead of the filesystem.

It would be nice to have an option to skip the initial scan of selected items which is apparently just for calculating progress, or for that to occur in the background instead of holding up the start of the copy operation.

My biggest gripe is the slowness of deleting large folders with lots of files, there surely has to be a faster way for that to be implemented considering there is actually no data copied at all. Being able to skip the initial scan for progress calculation would help.

I know that console commands can do it faster, but why not build some of that capability into File Explorer?

EDIT:
Wow! I just tried that remove-item command on an old fabs backup, 13GB of mixed size files. Only took about 2 seconds!
Thanks for that post @Mick

 

[Mick]

EDIT:
Wow! I just tried that remove-item command on an old fabs backup, 13GB of mixed size files. Only took about 2 seconds!
Thanks for that post @Mick

Thanks. Tell me - does the stuff go into the recycle bin, or is it gone for good? The latter, I'm assuming.

 

[fincoder]

gone for good

This.

 

[Diggs]

I can't remember but does something like Wiztree delete files as fast as it finds and displays them? I haven't mass deleted with it so I'm not sure. It could be a GUI option.

 

[britechguy]

Just used that

Remove-Item {folder} -Force -Recurse

command after having accidentally started the process in File Explorer and cancelling it after my patience for discovery was over.

The command, while not done instantly, completed the entire process for a folder containing at least 50GB of stuff in under 2 minutes, total. This one's going to be a keeper!