Changing the size of the read block will make copy faster but it will
lock the application even if you put it in a thread and that was my
main concern.
My method launches a shell ('cp source dest') in async mode and then
enters a loop until final size is reached, so that you can see copy
progress. This works great under mac and linux, under win there's the
limitation that the 'copy' command immediately creates a file with
the final size so you won't be able to see progress (but it will
result in a faster copy anyway). Under Vista there's 'robocopy' which
allows you get copy progress.
I'm not home and I don't have the code with me, but I don't mind
sharing code.
About the speed I didn't make specific benchmarks but it feels as
fast as manual copy and (most important) it doesn't lock the app
while copying. Try copying a large file, put your code (with the
1048576 block) in a thread and try doing something else in the app
meanwhile (for ex. browsing a listbox with many items).
Tomas
> I just tried copying *to* a USB thumbdrive, and there is quite a
> difference.
> Much slower. A manual OS copy is also slower than a HD copy.
>
> I changed the following...
>
> dstream.Write sstream.Read(8192)
>
> To...
>
> dstream.Write sstream.Read(1048576)
>
> ...and it made quite a difference in the transfer speed. It is
> nearly that
> of copying directly to the thumbdrive.
>
> Is the method you are using faster than a manual copy, about the
> same or
> less?
>
> If the performance is better, would you mind sharing your code?
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
