From: "Antti Kurenniemi" 

"Mike N."  wrote in message
news:2gev32985nehle8jsos7d9nmhpu266nrnf{at}4ax.com...
>>Yes but that's what the buffer memory in the drive is for, no need to try
>>to
>>implement a second buffer in the OS level.
>
>  Visualizing what the CopyFile routine does:
>
> R=read
> W=write
> I=idle
> S=Source Drive
> D = destination drive
>
> S D
> R I Start reading file 1
> R I
> R I   File1 completely read from source
> I W Start writing file 1
> I W
> I W File1 completely written to target
> R I  Start reading File 2
> R I.....
>
>  With a single threaded model, one of the drives is completely idle for
> half the time.     I don't know if CopyFile is internally multithreaded.
> In
> the normal case when the source and target are on the same device, it
> might
> not make sense to have it multithreaded.   When copying drive to drive it
> could clearly benefit.

No, it doesn't work like that. It starts writing to the second drive as
soon as there is some data in the read buffer from the first file. Think
about it, if file 1 was completely read before starting to write, you'd
never be able to copy files that are larger than your free memory size. And
if you copy a large file, do you see your memory size increasing? No, you
don't, because what happens is:

1. Open a stream to read from (source file). 2. Open a stream to write to
(destination). 3. Read a piece of the file from the source stream (block
sile, 512bytes or whatever it happens to be in the system). 4. Push the
piece into the destination stream, while continuing to read from the source
stream.
5. Repeat until read the file, and then go to the next file. Note, that
here the file may not yet be completely written to the destination, as
several megabytes may still be in the write buffer of the destination disk

The only case where the file read would be interrupted is if the disk to
write to (or the write operation to be more precise) is slower than the
disk to read from, in which case the write buffer is filled. And the other
way around, if the write operation is faster (newer disk for example), the
reading part will force writing to wait. Neither of these cases will be
helped by multithreading.

Old systems worked like you describe - I think NT4 did something like that,
which was a real pain if you copied something over the network because it
would open and close the stream for each file. But W2k and later are quite
a bit better at this.


Antti Kurenniemi

--- BBBS/NT v4.01 Flag-5