Similarly the integrity of the destination media should be checked before a copy is attempted. This should allow the OS to flag a problem via a trappable error of some sort thus allowing the user or program to select an appropriate response before a copy is attempted. It would seem that any method used to back up critical files should include opening the source file and attempting to read it first. Xcopy will not only skip the copy, but also delete the destination file (if it exists on the destination media) leaving you without your previously backed up file. Not much use though as the destination file might still be unuseable.Īnother problem with xcopy and /c is if the source file is locked. If the behaviour of XP's version of xcopy is the same as the DOS version then a faulty sector will be written out as rubbish to the destination file, but the rest of it should be copied faithfully. The Abort, Retry, Fail will still occur as a run time error, but can presumably be handled within the program. So if you need complete control over the copy process then PB's filecopy, or the Windows API would be a much better solution as you can programmatically adapt the desired response to your exact requirements. I know that xxcopy will return an error code if a copy fails, but it would seem that the only sensible way to use it this way would be to process each file individually, no wildcards in other words. No chance then for error trapping via a returned exit code or similar.įurthermore if xcopy is used with a wildcard then there probably isn't a way to extract the file name of the corrupt file as you noted previously. If the mechanism for running xcopy without /c is a batch file then the execution of the batch file would stop at that point until the user responds with the appropriate key press. If /C forces Abort, Retry, Fail to be ignored then it would be useless for flagging errors caused by a hardware problem like a bad disk sector. You are right Michael, the 'what' wasn't addressed and this forced me to read Mikes post properly. The only problem I've found with RoboCopy (W2K and XP), is that they don't handle DST time shifts well, and that will force a differential/mirror copy to copy all files two times a year. I don't know if there's a correspondingly newer RoboCopy for the Vista Resource Kit (nor Windows 7). The RoboCopy from the XP Resource Kit need XP to run (of course). Any alternatives? There is RSync - but that's LINUX). It has even more features, features you'll want after using RoboCopy for a while but didn't know you needed without RoboCopy knowledge (or a similar program. If you can, you should use the RoboCopy that came with the XP Resource Kit. It sets out to do major unattended copy jobs. It is fault tolerant - but only if you wish it to be - and you can make it report errors as they occur too. But you need minimum W2K to make it work.īeing console based, RoboCopy can be seen as a supercharged XCOPY replacement that does a lot more than XCOPY ever did. If you are in control of the PCs in question, you should definately take a look at RoboCopy, a utility MS first offered with the W2K Resource Kit.
0 Comments
Leave a Reply. |