Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently burned a disc with a TrueCrypt volume. The burning process was bad and several blocks (all in the volume) were corrupted. Perfect! i wanted to test how TrueCrypt can handle corruption. So i was able to mount the volume fine and open up documents and resource w/o problem. Now i want to copy it back to disc.

Problem, when copying one specific file the copy window locks up. Eventually a crc error occurs and explorer becomes slow until i unmount the drive. Looking at what was copied (one try), only 500mb came through. So

1) How can i copy as much files as possible (ignoring files that lock up and timeout/stop copying process) 2) How can i copy as many files as possible outside of truecrypt on disc that have crc errors? 3) Is there something else i can use to encrypt files? and wont give me a problem on a corrupted disc?

share|improve this question

I have not used TrueCrypt before so I am assuming that the copying part is just a plain disk to disk procedure. My suggestion would be to use xcopy to attempt to copy the files.

More specifically with the command -> xcopy /S /C

From the xcopy help : /S Copies directories and subdirectories except empty ones. /C Continues copying even if errors occur.

Hope it helps

share|improve this answer

By duplicating the disk to good media it will at least read the same.

On linux creating an image with dd_rescue is useful for this, although as with Windows you're going to want to let it run, less so then Windows, but Linux also doesn't like failing IO.

share|improve this answer

There is little point in adding additional redundancy to an encrypted volume which is why none of the programs do it. The programs usually expect the sublayers to work fine which is an ok enough assumption.

From experience, true crypt handles disk faults better than most as the file chunks are all uniform size. It can generally take more faults than a normal file system but will use slightly more space in doing so.

As for getting the data off, if its on a CD disk, then its just got to run. The lock up is in the atapi driver where the drive sits reading and rereading and the os can do nothing but wait for it. Linux handles it better when the cdrow drive is in userland. The xcopy command on windows/dd on linux is your best option. Just set it up, then go do something else till it copies off.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.