I was terribly busy working on a case this week. Many of the documents in the case were scanned in .TIF (also known as TIFF, Tagged Image File Format) format. So, browsing through the documents in this manner proved terribly inefficient and I didn’t have enough time to look into third party programs that might help me look through .TIF files faster. So, my solution was simple: I would take the CD full of sequentially numbered .TIF files and create a PDF out of them.
As I begun adding blocks of .TIF files to Adobe Acrobat, near the end of the disc, in the 6000’s, Acrobat would freeze up and hang and eventually result in a crash unless I ejected the disc. My assumption, was that certain files on the disc were corrupted either due to scratches or aluminum erosion/decay (they are very old discs).
Of course, there is no way to tell which files are corrupted this way. So, I decided to copy the entire folder of .TIF files to my hard drive to take note of the corrupted file(s). Big mistake. As Windows XP ran into corrupted files, it would halt for a tremendously long time, and then finally return an error:
Cannot copy 00006337.tif: Data error (cyclic redundacy error)
After I press “OK” I then had to re-select all of the uncopied files, avoiding the corrupted file, and then continue. This proved futile since there were various corrupted files scattered throughout the disc. (As a side note, a couple of fantastic tools for recovering data from damaged discs that I have personally tested are: photorec and object rescue). So, this seemingly simple task of “copy usable data from disc, ignoring corrupted files” has suddenly become a big problem on Windows XP and I am seriously short on time.
Without hesitation, I opened a new command prompt. I navigated to the directory of the files on my faulty disc and typed the following command:
XCOPY *.* “C:\CASES (Sam)\Clair\FPD CDs\FPD” /C
What does *.* mean? Well, it essentially means “wildcard dot wildcard,” meaning that I am stating any file with any extension. I type this because I am too lazy to type *.TIF since it’s the same thing. If, for example, I only wanted to copy the 00006000’s, I would type “00006*.*” Simple enough.
Note how I placed my destination folder in quotations? That stems from a long history of inconsistency dating back to the early DOS days when you had a 8 character limit. That was eventually extended in Windows95 which allowed for shortcuts for long directories in DOS like “C:\PROGRA~1” for “Program Files.” Putting quotation marks prevents (prevented?) DOS from interpreting a space as an end to your command.
Now, for the flag: /C. Doing a /? on XCOPY indicates:
/C Continues copying even if errors occur.
Exactly what I was looking for, right? Right there, in DOS, built right in. All you need to know is where to look to save lots and lots of time. After executing the command, it worked flawlessly without the need for any further user intervention:
(simple xcopy solution for bypassing erroneous data)
Hopefully you won’t have to put this technique to use, but if you do, it’s nice to know you have the right resources and knowledge at your disposal should you need them.
See also: Vista’s robocopy
As always, comment or e-mail with questions.
admin@variableghz.com
Fuck all that! I have shit to do man. Copying files is only one note in the symphony of drudge I’m expected to conduct and perform on a daily basis.
Wouldn’t it be nice if we could have a machine do this kind of repetitive crap for us? I like Teracopy. Tell it what to do for specific situations before hand, and when you check back on the transfer, it won’t have been sitting the on file number 236 of 865 for 36 hours waiting for you to press the “cancel’ button so it could quit and force you to try and figure out which goddammed file is the problem you have to identify and work-around.
Seriously, “cyclic redundancy” time is not “break -time’ you stupid computer. Just skip it and keep shoveling files until you get to the end or I tell you to stop. Ok? Ok.