Need to delete unmanageable Badmail directory

  • Thread starter Thread starter Charles Lavin
  • Start date Start date
Charles Lavin said:
What program will be loaded more than a half-million times? I'm using del.
When did del become an external program?
Click to expand...

See . . . that's what I get for working with *nix.

Still, the overhead of the directory searches will be a killer since
each execution will start searching afresh.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:[email protected]
Or to these, either: mailto:[email protected] mailto:[email protected] mailto:[email protected]
 
Define "safe and proven". Nothing is ABSOLUTELY guaranteed in this life, or
the next. As I said I have it used once before, and it was much faster than
regular methods. If that is not enough for you, feel free to revert to the
"safe and proven" DEL *.* or RD /S /Q.

Also if I can point it out to you, the "safe and proven" requirement
conflicts blatantly with your constant asking for a "fast" method of getting
rid of those files. I think it's time to decide what your priorities are.
 
ZVR said:
Define "safe and proven". Nothing is ABSOLUTELY guaranteed in this life,
or the next. As I said I have it used once before, and it was much faster
than regular methods. If that is not enough for you, feel free to revert
to the "safe and proven" DEL *.* or RD /S /Q.

Also if I can point it out to you, the "safe and proven" requirement
conflicts blatantly with your constant asking for a "fast" method of
getting rid of those files. I think it's time to decide what your
priorities are.
Click to expand...

You're addressing the wrong guy. I'm not the OP.

I have several degrees of "safe and proven":

Very safe = It's a native Windows tool.
Quite safe = It is a popular tool with a long track record.
Risky = No known track record.

I will use a risky tool on a workstation but only if I have a
recent partition image that I could use in case things go
wrong. On a server I would not use a risky tool - the risks
far outweigh the possible benefits.
 
You're addressing the wrong guy. I'm not the OP.

That's right, sorry about that.
I have several degrees of "safe and proven":
Click to expand...

So do I, I really thought I was responding to the OP and just wanted to
point out that usually things can be done the fast way or the safe way, and
it's up to each to decide what they need most. Again, sorry for the
misunderstanding.
 
Like I mentioned before, the time it was taking a "del *.*" to enumerate the
directory was leaving it susceptible to aborts that resulted in nothing
actually being deleted.

The server finished wiping out the directory, releasing about 7 GB of disk
space. At anywhere from a few hundred to a few thousand bytes per file, that
was a lot of junk in there ...

CL
 
But I wasn't dealing with a folder with 10,000 entries. At last count, there
were close to 2 million files in there.
 
If this had been a Unix machine, I would have figured out far more efficient
and quicker ways of wiping out that folder! <g>

I got the job done. The overhead of repeated single del calls might have
been more than we would have wished for, but we did get the folder emptied
one file at a time. I tried a few del *.*s, but came back to find the run
had mysteriously aborted and no discernible change in the amount of free
disk space.

CL
 
ARGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I went NUTS looking for something like this the other day, and didn't find
anything that would work ... This is EXACTLY what I was looking for. Oh well
.... the job is done. But I'll keep this for future reference!

Thanks!
CL
 
Hey -- I was willing to manually zero out the directory and let scandisk
pick up the pieces ... :-)

This is a machine that's being decommissioned. I had a full, verified
backup. If it had saved me the days of grief we ultimately wasted (which
resulted in the postponement of the actual migration for two weeks), you bet
I would have "risked" this tool. I desperately needed the disk space. And I
didn't want the slightest risk of this folder being migrated to the new box.
Plus, the sheer size of the file table was getting in the way of everything
else we were attempting to do ...

CL
 
Back
Top