What do you think your answer is likely to be?

Anyway, as you say yourself, Perl does the job adequately. However, copying a file from one machine to another is not exactly rocket-science - there are probably a zillion and one different ways to get the job done. I've never even heard of Robo Copy, so I can't comment on that. However, is it really such a big deal? It's just copying a file - who cares how it gets done as long as it gets done?

Don't sweat the small stuff, I say :)

Robo copy may be http://www.robocopy.net which appears to be an online backup facility. If that's the case, the outcome of using robocopy may be different than the outcome of copying a file from one server to another with a Perl script. robocopy probably moves the file to www.robocopy.net's online backup servers, which he probably couldn't do without using their proprietary software. ...all this is speculation of course, but I'm guessing that if the server admins wish that he use a specific online backup service instead of his script, the decision isn't really his anyway, and even if it were, he's not really comparing apples with apples.




Dave

No, robocopy (a "robust file copy utility") comes with the Windows Resource Kit and has done since NT 4 and possibly earlier.

/J\

Have you tried it yourself?  If so, was there any difference in speed?

Did the Server Admins give you a reason why they wanted to use "Robo Copy"?  Is it because of a perceived efficiency?  Some other tasks already use "Robo Copy" as well?   The reason I ask is, why change it if it's working.  If your task is I/O bound (which I'm sure it is, with a 3MB file), there shouldn't be a significant difference in transfer time.

Update:  ++McDarren on the great analogy!  It so nicely painted for me a picture of the "Server Admins", defending their point because they all own BMW's, but haven't necessarily ever driven a Mercedes... ;-)

Update2:  I see that I haven't ++'d McDarren yet, just made a mental note to do it, so that really should have been McDarren++ above...

I hate to say it but it is likely that robocopy is going to be the more efficient and safe solution for server to server copy. It has a almost bewildering array of options that allow you to specify how the copy will be performed and performs a "deep copy" that can copy the ACL and Security descriptors of the files. Being part of the Windows Resource Kit it is likely to fall more squarely within the server admins experience and comfort zone than a home brewed copy program.

That said if any additional processing is to be done on the files and your program already does it then moving to a robocopy and windows batch script process is probably not worth the effort as doing anything more than trivial in a batch script is horribly painful in my experience and I always turn to another language, even VBScript is preferable...

/J\

There is nothing AFAIK to prevent you using ROBOCOPY from a perl script. windows/DOS batch file sucks wind badly, and you shouldn't even consider touching it with a 10 meters pole once you tried Perl (or Ruby or Python or even bash).

PS: ROBOCOPY is a decent tree copy utility from the Microsoft resource kit, somewhat similar to XCOPY but better, because it can copy efficiently thru the network and copies ACLs too.

I used RoboCopy a year ago and It is very good, specially with the automatically daily copy options.

Please use the last version! (XP10, maybe)

And, of course... Write a Perl script to monitoring the existence of robocopy process... sometimes, it crash!

In few words, Robo is best because all options can be set at command line or short config file, include the repetition of daily process... but is not reliable.

Thanks for all your replies and time.

It sounds like Robo copy is a good option and I assume it has logs to follow if the copy was successful. I will have to wait for them to implement the Robo copy within the next day.

However, since the SysAdmins and DBAs want something to manage, and they put RoboCopy into place, I'm happy to leave it to them. Even if I had a better widget on the shelf.

Just for reference, our servers hold about 700G of data. We obviously don't copy everything every night (or it would take quite some time). But it's no slouch, either, we do at least 60G every night starting at 10:00PM, and it manages to stay out of the way of most of my batch jobs... (Thank goodness for multiple fibrechannel cards and the EMC box...)

--roboticus