ERROR: "File or directory is corrupt and unreadable"

This error occurrs in Windows Explorer, the command prompt (cmd.exe) and similar messages are produced by other applications trying to access directories or files restored as follows. Using the bootabe Rescue Media component of TrueImage Home 9 (Build 3677) to do a "Files or Folders" (as opposed to a "Disks or Partitions) restore, possibly when restoring to a "New location" (as opposed to "Original location") has produced directories / files that exhibit this behavior. Further, affected files / directories are not able to be deleted, moved, or otherwise accessed.

I am posting this to generalize the discussion found in this thread:

https://www.wilderssecurity.com/showthread.php?t=145505

in the hopes that more affected users will benefit from increased visibility into the issue.

There you will find a discussion of the problem as encountered by more than one user, as well as my story of how I was able, in my particular case, to finally remove the affected directory.

Acronis, please advise as to your position on how to "officially" fix the problem resulting from use of TrueImage Home 9 in the maner described above.

Thank you,

-- Curt.

 

Could not recreate the problem. Did a file/folder restore to a different partition on the same physical drive as well as to a completely different physical drive...all usable with no errors.

 

The following"

Seems to imply you were running TI9 under Windows from a different partition on the same physical drive... is that correct?

This problem seems to occur when using TI9 after booting from Rescue Media.

It seems related to a corrupton of the internals of the NTFS file system, but that's not confirmed. Given that presumption, though, if you try it on a fairly empty partition (i.e., one with a very simple file system on it), you might not get the error. Usually these things come up around boundary conditions that are not sufficiently tested. So try copying a lot of files and directories onto the partition you're testing with so that the internal data structures are not overly simplified. In my case, the partition had almost 70GB of data in close to 163,000 files and 14,000 directories. If someone used INT instead of LONG somewhere, that's when things break, but you don't find out until the numbers start to get large.

Note that Christopher_NC experienced the same behavior, so the problem is reproducable. (I am not Christopher_NC, too!) See his original post in the thread referenced below.

Thanks for trying it out.

 

Hi all,
I am suffering the same problem. I have read the posts by following the link mentioned above, but all of that is Greek to me. I'm not a Windows guru. And I'm getting worried now. Might there be someone who has a solution that a common Windows user can understand and apply?

Thanks,
Jacob

 

Jacob,

I just posted a fix that might help you clean up your corrupt directories in the original already linked thread on this subject (a thread that did get quite technical). Here's my suggestion:

If you overwrite the corrupt files (created from a Files & Folders restore in TI Boot Mode) by doing another restore with TI running in Windows of the same files to the same new location and specify in the Restore options to overwrite the existing files, in my case, it did, and resulted in a clean directory structure and usable files. After a reboot (apparently to correct the corrupt directory structure detected by TI during this restore) chkdsk ran, and all seems to be intact.

I'll add that, unless you actually overwrite the corrupt folders, this process will not work. So, if you told TI in boot mode to restore to a given Partition, or folder, use that exact same destination when you restore the files in Windows. Otherwise, after my first attempt to do this cleanup today, there was a new, intact folder [Drive (H) in my case] as a subdirectory of the corrupt Drive (H). If at first you get this result, try again. Once overwritten by the Windows version of TI Files & Folders Restore (which seems to be able to handle this task correctly) your errors should be gone.

I hope this helps. You might also add some details about your experience, such as the type of source and destination drives or partitions, etc. SATA/IDE/ external USB...this may help narrow down the conflicts.

In my tests today, I tried using a new TI Boot disk with the latest Acronis Drivers, but still ended up with corrupt directories in certain instances.

 

Hi Christopher,

Many thanks for your answer and tips.
The problem occurred on my C: (boot) partition. I’m using Build 3694 (Dutch language version). I followed your instructions to the letter, but it did not work for me. I ended up still having the corrupted file and a (good) version of the file with the same name and a generated filename extension. I tried it several times with several 'clean, unaffected' images, but everytime the result was the same.

Then I made a full restore of the C: partition using the secure zone (with an image of 3 days old), the only thing I could do IMHO. One of the steps was 'removing the old partition' so I figured it would format a new one.
The recovery using the secure zone worked flawlessly! And after that (35 minutes for a 109 Gb recovery) my system was OK again: the 'corrupted' folder containing the corrupted file was gone and it looks as everything else is OK. No more chkdsk’s after a reboot and defragging the C: partition works OK again (defragging was refused because C: was 'marked for chkdsk /f').
I restored some newer files from a more recent image, made just a few hours before the problem occurred.

And now I’m back in bussiness again.

Many thanks for your reaction and have a nice (rest of the) weekend.

Jacob