But I don't really understand your question. You can't really speed up the process - at least not by using different statements in your program (you might be able to tune your OS that copying huge files goes faster). I don't know why you are considering a timer, and I've no idea what you mean by "copying until EOF to delete the file once it finished copying".

I would do the thing you're doing from the command line, and skip the Perl part:

    find M:/Directory -name '*.BAK' \
         -exec mv {} 'I:/(Directory0)/(Directory1)/(Directory2)/{}' \;
[download]

Abigail

Sorry for stating this so flatly, but you should really do a checksum on the original and compare it to your copy before unlink()ing the orginal. Have a look at Digest::MD5, which seems to be very popular. You could also call the *NIX command 'cksum' (which probably has been ported to Windows, or at least has an equivalent) and get very similar results.

Also, when handling errors, try 'die' instead of 'print', so Perl will return the right error level: unlink( "$_" ) or die "Couldn't delete file: $_\n"; If you add an 'or die' to the copy operation, it will only attempt to delete the orginal if the copy is successful.

Doing a checksum will effectively double the transfer time because the files need to be read back from the remote location. Especially since a network filesystem copy is fairly reliable since the OS does some error recovery.

Well, yes. That's a good point. But no one said the checksum has to be done from the remote system. ;)

--
Allolex

scp -CBvrp srcpath user@host:destpath
     |||||
     ||||+-- Preserves time stamp
     |||+--- Recursively copy entire directories.
     ||+---- Verbose mode useful for logging
     |+----- Batch mode
     +------ Enable compression accross network

and then...

del /S *.BAK     # recursively delete BAK files
[download]

This assumes that the extra CPU juice needed to encrypt/decrypt and compress/decompress 6gb will allow the transfer to happen at the same rate or faster. It may or may not, but I assume if his network can't transfer raw 6gb faster than he has stated, the CPU's (and memory) plugged into such a network may be an even tighter bottleneck.


-Waswas

You don't mention how far apart the source and destination are, or whether they're attended by people (as opposed to running in a dark colo somewhere). If the servers are close, there's an option we often forget: use removable drives. It take considerably less than an hour and a half to copy 6Gb of data at IDE (or SCSI) speeds, remove the drive, and walk it across the room to the backup box.

Or, if the source and destination are far apart and "latency" isn't critical, shipping a removable drive via FedEx can still yield reasonable bandwidth.

It might be an option to consider.

Depending on the nature of your file (does every single byte change every time you need to copy it?) rsync can also improve efficiency. It can also use ssh compression similar to the scp already mentioned if that helps your transfer.

(Or it could be much less efficient...in which case don't use it.)

Do alot of testing of this method first. :-) But it would give you some protection against one of the network connection hanging, causing loss of a partial file. It may also speed up your transfer, with parallel file transfers.