🚀 go-pugleaf

Andrue Cope wrote:

>On Wed, 02 Jun 2004 17:00:04 -0700, Bob Gonder wrote:
>
>> Once I've copied a couple files, (MB/sec is tricky when MB is small)
>> the rest copy in the desginated time (pretty close).
>
>Two things can seriously throw the calculation in my experience:Copying
>subdirectories and copy across a network. Nonetheless the OS provided
>estimate is appallingly bad.

I haven't found the network to be a problem, but then I don't have any
other users on it <g>. Subdirs I handle with a thread that right after
selection, recurses and adds up all the files. Usually completes by
the time I pick a destination.
The Other problem is MS's lazy writes.  The first couple Megs really
fly because they're just queued, then when the que fills, throughput
crashes.

>I have a windowed XCopy replacement that uses up to five threads to read

That's what I was after doing, but so far, just does dirs/subdirs,
copy or move, overwrite, rename or leave alone, never stop for errors.

>The only problem with that app. is that since it copies files byte-by-byte
>it can be slower if both the source and destination are compressed. I just
>haven'd had the time or inclination to look into that. I think I'd have to
>change to using CopyFileEx() to get round that.

Yeah, it's definately easy to use. Just wish there was a MoveFileEx
with a callback.