Prev: Connecting to a WAN
Next: Datagridview -- problems in Backgroudworker
From: Patrice on 14 Oct 2009 07:07
I would time how much time it takes using the "rd" command line.

It would likely give a realistic target and would allow to see if the .NET
framework seems to be optimized or does additional checks or work that could
slow down this process.

Technically speaking all entries needs to be cleared (the file size is not
relevant, the number of files and folders is more likely what matters)...

--
Patrice


"Scott McNair" <smcnair(a)beachexpress.takethispartout.com> a �crit dans le
message de groupe de discussion :
Xns9CA37F46A3EF0donquixote235gmailco(a)207.46.248.16...
> Is there a way to "instantly" delete a folder and all subfolders? I'm
> currently trying:
>
> System.IO.Directory.Delete(Filepath, True)
>
> Each of these folders contains 60 subfolders which in turn contain about
> 100 files each (each of which is about 180kb). Because of this, my
> application grinds to a halt.
>
> Is there a way to simply flag a folder and its contents as deleted without
> having to go through the recurse?


From: Scott McNair on 14 Oct 2009 11:54
"Miro" <miro(a)beero.com> wrote in
news:#mRD#dETKHA.1232(a)TK2MSFTNGP05.phx.gbl:

> I have never tried this... but you got me thinking...what about not
> "deleting" but moving the folder to the recycling bin....
> I found this...
> (again - I have never tried this, and do not know if this will work
> with folders)
> http://visualbasic.about.com/b/2006/12/22/recycle-files-with-vbnet-2005
> .htm

Good find! I may use it for other applications. On this one, however, I
need the files to actually go away (to free up disc space) so simply
recycling them is not an option.

Thank you for the link though.
From: Scott McNair on 14 Oct 2009 11:57
"Alex Clark" <quanta(a)noemail.noemail> wrote in
news:eaAcdIDTKHA.220(a)TK2MSFTNGP02.phx.gbl:

> But if your app is grinding to a halt, why not just run the delete op
> on a background worker thread?

That's exactly what I wound up doing, thanks.

The application that creates the files does it via threading, so we may
have up to 32 different threads writing to the drive. Needless to say my
non-threaded delete application was unable to keep up (even disregarding
the hang-up issues).

By threading the deletes, the application seems to be deleting faster than
the files are being created, although just barely. But in this case,
barely is good enough (at least for now).
From: Michael D. Ober on 14 Oct 2009 18:48
"Scott McNair" <smcnair(a)beachexpress.takethispartout.com> wrote in message
news:Xns9CA46F5FCD903donquixote235gmailco(a)207.46.248.16...
> "Alex Clark" <quanta(a)noemail.noemail> wrote in
> news:eaAcdIDTKHA.220(a)TK2MSFTNGP02.phx.gbl:
>
>> But if your app is grinding to a halt, why not just run the delete op
>> on a background worker thread?
>
> That's exactly what I wound up doing, thanks.
>
> The application that creates the files does it via threading, so we may
> have up to 32 different threads writing to the drive. Needless to say my
> non-threaded delete application was unable to keep up (even disregarding
> the hang-up issues).
>
> By threading the deletes, the application seems to be deleting faster than
> the files are being created, although just barely. But in this case,
> barely is good enough (at least for now).


Would a better design be having the application that creates the files
delete them as well, or are they needed by the application that does the
deleting?

Mike.

From: Patrice on 15 Oct 2009 13:04
Or perhaps a file watcher ?

Most often it's better to give an overview of what you are trying to do in
case another approach would work (even possibly without using files ??)...

--
Patrice

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam.> a �crit dans le message de
groupe de discussion : DJ6dnY0WusHfyEvXnZ2dnUVZ_vednZ2d(a)earthlink.com...
> "Scott McNair" <smcnair(a)beachexpress.takethispartout.com> wrote in message
> news:Xns9CA46F5FCD903donquixote235gmailco(a)207.46.248.16...
>> "Alex Clark" <quanta(a)noemail.noemail> wrote in
>> news:eaAcdIDTKHA.220(a)TK2MSFTNGP02.phx.gbl:
>>
>>> But if your app is grinding to a halt, why not just run the delete op
>>> on a background worker thread?
>>
>> That's exactly what I wound up doing, thanks.
>>
>> The application that creates the files does it via threading, so we may
>> have up to 32 different threads writing to the drive. Needless to say my
>> non-threaded delete application was unable to keep up (even disregarding
>> the hang-up issues).
>>
>> By threading the deletes, the application seems to be deleting faster
>> than
>> the files are being created, although just barely. But in this case,
>> barely is good enough (at least for now).
>
>
> Would a better design be having the application that creates the files
> delete them as well, or are they needed by the application that does the
> deleting?
>
> Mike.
>

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Connecting to a WAN
Next: Datagridview -- problems in Backgroudworker