Getting rid of a large folder

[W. eWatson]

I have a 6G folder, and putting it into the recycle bin is very slow.
How can I just get rid of it?

 

[VanguardLH]

I have a 6G folder, and putting it into the recycle bin is very slow.
How can I just get rid of it?

Turn off the Recycle Bin. Then delete.

The Recycle Bin works as a first-in, first-out buffer. The oldest files
in it are deleted first to make room for the next file. Enough of the
old files are removed as to make room for the next file to come in.
This is done ONE FILE at a time: the old files are deleted to make room
for ONE file coming in, and the process repeats for each single file
coming in. If you delete N files then N times are old file(s) delete to
make room for ONE file. It is a slow process.

If you turn off the Recycle Bin then it's not having to store the newly
deleted files. The delete operations will progress as fast as the
system API can handle them.

 

[Bruce Hagen]

I have a 6G folder, and putting it into the recycle bin is very slow. How
can I just get rid of it?

Shift + Delete bypasses the Recycle Bin.

 

[W. eWatson]

Shift + Delete bypasses the Recycle Bin.

I'll try it. Thanks.

 

[W. eWatson]

I'll try it. Thanks.

It sure is slow.

 

[W. eWatson]

It sure is slow.

I found one interesting reason why this is so slow. This PC has been in
op for 5 years, and data is frequently deleted from it, which in turn is
filled again with new data. When I started a de-frag, the analysis
showed almost nothing but red lines.

 

[Bruce Hagen]

I found one interesting reason why this is so slow. This PC has been in
op for 5 years, and data is frequently deleted from it, which in turn is
filled again with new data. When I started a de-frag, the analysis
showed almost nothing but red lines.

A defrag sure can't hurt anything and will likely help. That may take some
time, but don't give up on it.

 

[VanguardLH]

I found one interesting reason why this is so slow. This PC has been
in op for 5 years, and data is frequently deleted from it, which in
turn is filled again with new data. When I started a de-frag, the
analysis showed almost nothing but red lines.

I don't think a highly defragmented partition is going to affect
deletions. Those are removals from the file system, not overwriting
each cluster with zeroes - unless you were using some 3rd party "secure"
delete that not only removes the file's *pointer* from the file system
but also overwrites the space occupied by the file.

Are these a ton of tiny files? Files under 1.5KB in size are actually
stored *in* the MFT (master file table). Rather than use that file
entry as a pointer to a small file (which would have a large amount of
slack space because it didn't fill a cluster), that same space in the
MFT is used to actually hold the content of the small file. This also
optimizes file I/O (reduces overhead) because the disk head is already
atop the sector in the MFT to find out where is the file but that small
file is right there instead of a pointer that has to move the head to
some other place on the platter(s).

You could wait until the defrag completes and then do the deletes but
then you'll have to do another defrag considering the huge number of
files that you are deleting (and after you empty the Recycle Bin which
probably holds nowhere near as much as what you are deleting).

 

[W. eWatson]

A defrag sure can't hurt anything and will likely help. That may take
some time, but don't give up on it.

10 hours later it's at 11% finished. Unfortunately, my free space was
down to 10%. I'll keep running it until it's finished. I hope the HD
doesn't heat up.

 

[W. eWatson]

I don't think a highly defragmented partition is going to affect
deletions. Those are removals from the file system, not overwriting
each cluster with zeroes - unless you were using some 3rd party "secure"
delete that not only removes the file's *pointer* from the file system
but also overwrites the space occupied by the file.

Are these a ton of tiny files? Files under 1.5KB in size are actually
stored *in* the MFT (master file table). Rather than use that file
entry as a pointer to a small file (which would have a large amount of
slack space because it didn't fill a cluster), that same space in the
MFT is used to actually hold the content of the small file. This also
optimizes file I/O (reduces overhead) because the disk head is already
atop the sector in the MFT to find out where is the file but that small
file is right there instead of a pointer that has to move the head to
some other place on the platter(s).

You could wait until the defrag completes and then do the deletes but
then you'll have to do another defrag considering the huge number of
files that you are deleting (and after you empty the Recycle Bin which
probably holds nowhere near as much as what you are deleting).

See reply to Bruce.

This is a result of an astro camera catching sky images about 8-10 hours
a day. Lots of variety in size, but there are some big files in there.
jpg, and I think short videos that the length in time of a meteor track.
That mixed with periods where I did delete files of little use. A really
mixed bag of activity.

I'll wait it out and hope that I can really delete the useless data out
of the way.

I'm replacing an old camera operation with a new one. It will add new
data up to a limit, and then rewrite over the old stuff after x days.
This almost sounds like it's begging for defrag problems.

 

[Paul]

See reply to Bruce.

This is a result of an astro camera catching sky images about 8-10 hours
a day. Lots of variety in size, but there are some big files in there.
jpg, and I think short videos that the length in time of a meteor track.
That mixed with periods where I did delete files of little use. A really
mixed bag of activity.

I'll wait it out and hope that I can really delete the useless data out
of the way.

I'm replacing an old camera operation with a new one. It will add new
data up to a limit, and then rewrite over the old stuff after x days.
This almost sounds like it's begging for defrag problems.

Now that you know the thing has horrible file system characteristics,
you should be using a "scratch partition" and just format the thing
when you want to clean up. Formatting, is the fastest way to defragment...
Since you know the application has a fragmentation pattern to it, plan
in advance for the inevitable conclusion (slow slow performance). Blowing
away the partition will take no time at all.

Paul

 

[W. eWatson]

Yikes. Had a power outage, so have restarted the defrag. Interestingly,
it's 3% complete, but working on compacting files. I guess that's
supposed to help.

It is showing small signs of progress.

 

[Paul]

Yikes. Had a power outage, so have restarted the defrag. Interestingly,
it's 3% complete, but working on compacting files. I guess that's
supposed to help.

It is showing small signs of progress.

If it's not a system volume, it may be faster to copy the files off,
reformat, then copy them back. I've even done that to my
system volume, but the procedure is more involved ("fixboot" is
the last step in the procedure).

Paul

 

[John John MVP]

Yikes. Had a power outage, so have restarted the defrag. Interestingly,
it's 3% complete, but working on compacting files. I guess that's
supposed to help.

It is showing small signs of progress.

If the disk has little free space available it will take forever to
defragment. The defrag engine has to move the files to a different area
on the disk to free up enough contiguous space and it then moves the
files back to the contiguous space. When the disk has little free space
available the this back and forth moving of the files is laborious. I
would get rid of some files and free up additional disk space before
trying to defrag it. Ccleaner can help with the cleaning of temp files.
http://www.piriform.com/ccleaner

John

 

[W. eWatson]

Another option is to use the command shell and use "deltree" - just be
careful in how you use this, as it deletes the directory and its
subdirectories (and the files within). You can read up on it. You need
to specify the directory name as an argument in the command line, but be
sure to get it right, as there's no going back.

Sounds to dangerous for me.

 

[W. eWatson]

If the disk has little free space available it will take forever to
defragment. The defrag engine has to move the files to a different area
on the disk to free up enough contiguous space and it then moves the
files back to the contiguous space. When the disk has little free space
available the this back and forth moving of the files is laborious. I
would get rid of some files and free up additional disk space before
trying to defrag it. Ccleaner can help with the cleaning of temp files.
http://www.piriform.com/ccleaner

John

Maybe there's a control to ccleaner, but the last time I used it, it
reset way too much. Especially in FFox. Lots my history file. Of course,
it's now working.

Somehow I managed to free up more space, and got to 17% of free space. I
just checked the progress, and it's looks encouraging. 37% complete. So
far its been running for about 24 hours+.

I recall years ago that when I updated from Win NT to W2000 the install
was very slow. It took 24 hours, but worked quite well when finished.

 

[Nil]

Maybe there's a control to ccleaner, but the last time I used it,
it reset way too much. Especially in FFox. Lots my history file.
Of course, it's now working.

You have total control over CCleaner. It won't delete anything unless
you tell it to. If you lost your history, it's not CCleaner's fault,
it's yours.

 

[W. eWatson]

You have total control over CCleaner. It won't delete anything unless
you tell it to. If you lost your history, it's not CCleaner's fault,
it's yours.

Actually, it's HP tech supports fault. The suggested it without any
cautions. However, as I've used my system, things (history, in
particular) are doing fine. Nevertheless, when one suggests ccleaner, it
should carry a warning.

 

[W. eWatson]

Turn off the Recycle Bin. Then delete.

The Recycle Bin works as a first-in, first-out buffer. The oldest files
in it are deleted first to make room for the next file. Enough of the
old files are removed as to make room for the next file to come in.
This is done ONE FILE at a time: the old files are deleted to make room
for ONE file coming in, and the process repeats for each single file
coming in. If you delete N files then N times are old file(s) delete to
make room for ONE file. It is a slow process.

If you turn off the Recycle Bin then it's not having to store the newly
deleted files. The delete operations will progress as fast as the
system API can handle them.

I wish I had noticed this branch sooner.

 

[W. eWatson]

BTW, how do I do that?