Boot Mode Files & Folders Restore: PDF file corrupt and unreadable

Using TI 9.3677 in Boot Mode to restore Files and Folders (F&F) to a new location produces some corrupt files & directories.

I'm testing with the file: TrueImage9.0 User Guide.pdf
TI validates the F&F archive, and reports the restore operation as successful. But, as the Screen Shot below shows, the TrueImage PDF file is corrupt and unreadable, and won't open. And, the newly created directory "Drive (H)" is corrupt, and cannot be deleted, at least not in Windows.

I've tested this several times to both internal SATA hard drives and an external USB hard drive with the same results. Corrupt directory, and a PDF file that looks fine, until I try to open it, then the error message below. Interestingly, a small text file restored in Boot Mode on the same restore operation came thru intact, and opens fine. So size may matter here TI9.0 UserGuide.pdf is 2.2 MB, while the Adaptec USB Driver Readme.txt is 9 KB.

Boot Mode TI can restore the PDF file to the original location successfully. TI running in Windows XP can also restore the PDF file to a new location intact, with no corrupt directory. Boot Mode TI can restore the drive partition image with the PDF file successfully. In fact, the only way I've found to clean up the corrupt directory is to either backup the rest of the files and folders on the partition (leaving out the corrupt directory), reformat the partition, and then restore the files and folders, or, to use TI to quickly restore a clean Image of the Partition.

Is this a known issue, and will it be resolved in the next build?

I've searched these forums, and found a few related reports, but not this exact issue. I'd like to know if this is unique to my system -- though I doubt that it is. Seems related to the original or new location, and not hardware dependent.

If anyone is up for a test, please try using TI Boot Mode to restore a .pdf file to a new location, from a Files and Folders Archive. If you do, either use a partition you have nothing important on, or be prepared and make an Image of the partition before you run tests. When I first encountered this, it was on a full partition with 70 GB of TI Archives. Cleaning that up took some time.

Windows' support website suggested the cleanup option of backup intact files/format partition/restore. Here's a Microsoft support link to what might be a similar corrupt directory problem:

http://support.microsoft.com/default.aspx?scid=kb;en-us;246026

Windows Support says Checkdisk won't see the Master File Table naming issues, and Checkdisk did not resolve them here. The drives are NTFS. File security settings (preserve or not, on creation or restoration) don't affect these results...File ownership didn't effect the corrupt directory.

 

Hello Christopher,

Thank you for choosing Acronis Disk Backup Software.

Please accept our apologies for the delay with the response.

I've just tested it myself and was unable to reproduce the problem you described. I have tried restoring files and folders inlcluding Acronis True Image 9.0 Home User's Guide both preserving and not preserving their security settings to both their original and new location. The restored files and folders including .pdf documents are always readable independentely of their size (I also tried restoring very small text files). I used Acronis True Image 9.0 build 3677 on Windows XP Professional based machine.

First of all, please make sure that your Bootable Rescue CD is created with the latest build (3677) of Acronis True Image 9.0 Home. You can check this by going to Help -> About menu when your computer is booted from Acronis True Image 9.0 Home Bootable Rescue CD.

If the problem persists with Bootable Rescue CD created using the latest build (3677) of Acronis True Image 9.0 Home, please submit a request for technical support containing the following information along with the link to this thread. We will investigate the problem and try to provide you with the most suitable solution as soon as possible.

- After the files and folders in question are restored, please create Acronis Report and Windows System Information as it is described in Acronis Help Post;

Please keep the hard drive where the restored files and folders are located connected and powered on while creating Acronis Report.

- Boot your computer from Bootable Rescue CD created using the latest build (3677) of Acronis True Image 9.0 Home and create Linux system information (sysinfo.txt) as it is described in Acronis Help Post;

- Where do you store the file-based backup having the issue?

- What locations did you try to restore this file-based backup to?

- What happens when you try to delete the restored files and\or folders? Do you receive any error messages when you try to delete them?

- Describe the way you created\restored this particular backup archive in more details. Did you adjust backup archive creation\restoration options in any way?

Thank you.
--
Alexey Popov

 

Hi Christopher,

Very strange. I too have tested your scenario and am unable to replicate the problem.

Perhaps the problem is related to your Adobe Reader so might be worth trying the following (copied from the University of Sidney Library website):

Regards

 

I *AM* having the same problem Christopher describes.

TrueImage Home 9.0 Build 3677, booting from Rescue Disk, results in the "File or Directory is corrupt and unreadable" error.

One slight difference from Christopher's post.

My file was a small text file (732 bytes), so I don't think it's a size issue.

Also, it's the final directory in the tree that TI (from Rescue Media) has problems with. Mine created the 'Drive(C)', 'Documents and Settings' and %userprofile% ('cuequi' in my case), but it is the 'Desktop' directory in which the file actually resides that is corrupt.

Another interesting point... If you use the Rescue Media to do a Backup, you ***CAN*** see the file you restored in the directory XP thinks is corrupt.

Perhaps that there's something flaky about the file system (NTFS)driver used by the OS on the rescue media?

I haven't investigated, but anyone know what the OS and NTFS driver are?

If we could boot into the same OS with the same file system driver, perhaps we could use it to remove the directory via the shell or something like that.

The Microsoft KB article that seems most relevant is here:

http://support.microsoft.com/kb/246026/en-us

While it says it's regarding NT4 and Win2K only, it's not beyond Microsoft to be a bit behind.

CHKDSK /r, from both Windows (which schedules it for the next reboot) and via the Recovery Console, does nothing to fix the problem even after multiple iterations. So MS was right in that regard.

I've tried loading the Windows Services for Unix from Microsoft to give me a POSIX-compliant shell. A few folks had reported success under Win2K deleting files and directories exhibiting the same behavior (although not known to be caused by TrueImage) using Win2K's POSIX shell and the 'rm' command that came with the Win2K ResKit. Problem is that MS has revamped the POSIX subsystem entirely for XP, so I didn't have any luck. Others with XP reported similarly. One said he had success using 'rm' under Win2K's POSIX to fix the FS on a drive formatted by XP. I haven't gone that far yet. See this post: http://groups.google.com/group/micr...a83?lnk=st&q="rm.exe"&rnum=1#a1577b1625a2fa83

What I've been spending most of my time doing has been researching the NTFS internals so that I can determine if what Microsoft says is the problem is in fact the problem.

I think I'm going to try another take on this today, though.

I'm going to try Bart's PE first and see if I can delete the directory from the shell there. If not, I'm going to dig into the rescue disk and see if I can't figure out what (if any) file system driver is used to create directories under whatever OS it's using.

If anyone has tried the above, I'd love to hear your experiences.

-- Curt.

 

Greetings, Curt,

Good to know that I'm not alone in my findings. You asked what OS True Image uses in Boot mode. All I know is that it's a Linux kernal based OS. A person who may know is Mustang, who has written TI Plugins to run under ReaTogoPE. You are far ahead of me technically, but I suspected that the Files and Folders program did something incorrectly while creating those new directories in NTFS, and think you are on the right track.

I would like to see the Acronis Boot environment offer more to users than simply loading Acronis programs. Once there, we could, as in this instance, delete corrupt files or directories, and even, perchance, run a chkdsk like utility? Would it not make sense to include that function in a boot mode of True Image, since, as it turns out, TI is capable of corrupting our directories? If we the users can't be trusted to over-ride TI functions, then how about offering undo options, which are common in other disk utilities I have used?

Perhaps my older Socket A PC doesn't have all the features TI needs to run flawlessly. From what many report in these forums, many newer PC architectures aren't a good match for TI, either. Perhaps Alexey will give us the details of his hardware, so that we will at least have a start on the known hardware compatibility list for TI 9.3677.

 

Menorcaman,

Your suggestion for modifying settings in my Acrobat Reader worked well - thank you - at least for downloading and opening the new TI 9.0 User Guide tonight. At least it's newer than the one I received with my purchase of True Image 9 on June 1st, 2006. There's even a section on File-level security settings, 6.4.4, which I found surprisingly absent when I searched for them while conducting these recent tests. Having already purged my corrupt directories, I haven't tested that PDF file yet.

I'll do more testing in the coming days, and try to answer Alexey's questions. I doubt that the Acrobat Reader fix will have any affect on the corrupt directories I've been producing with Files and Folders restore, however.

Regards

 

OK. A couple of updates.

First, I was mistaken in my earlier post when I said that the TrueImage application running from the Rescue Media was able to see the file restored. That was **incorrect**. My appologies. I can only see the "corrupt and unreadable" directory.

Second, I did a little investigating on the Rescue Media itself. Turns out it is a Linux 2.4.32 kernel, but, not being a Linux guru, I can't tell what distribution. Perhaps someone with more familarity with the directory structures and files particular to the various distributions could tell, but I can't.

The Rescue Media actually has a method to get you into a Linux shell (Busybox, actually). See https://www.wilderssecurity.com/showthread.php?t=55317, under Section II(b). I guess it pays to read the "Readme" first. Basically, after you reach the menu screen, hit <F11>, clear the dialog box, hit <OK>, then click <Full Version>. You'll get a Busybox.

That's the good news. The bad news is that there isn't much else there. The one thing I did discover is that it doesn't look like TrueImage is using a kernel driver (like Captive or the one at www.linux-ntfs.org) to write to the volume. I didn't see any relevant libraries in /lib, and 'mount -t ntfs' didn't work.

I'm guessing that TrueImage has its own mechanism for reading/writing NTFS volumes (if it can interpret the file system from a drive image, why not, right?), but I'm not sure about that.

At any rate, going through all of that gave me another idea. In addition to checking out whether BartPE might be of any assistance, there are a number of folks who have created bootable Linux CDs -- Trinity Rescue Kit, for one -- with NTFS write-access enabled. Trinity happens to use the linux-ntfs.org libraries and progs, and I'll bet there are others with different mechanisms, like Captive, etc. Perhaps one of those, or BartPE, will be robust enough to allow me to 'rmdir' the "corrupt and unreadable" directory without trashing the file system.

If I ever achieve success (other than a reformat of my partition!), I'll provide an outline of what works.

Please let me know if anyone else has other thoughts / suggestions (like if you tried this before and it did / did not work).

I'll keep you posted.

-- Curt.

 

Curt,

Thanks for all the excellent detective work! Sounds like you are set on finding a way to access and delete those corrupt directories. And well you may. Your diligence is much appreciated.

In the meantime, or for anyone else faced with a similar situation, there is the option of making a files and folders backup of the intact portions of the partition with TI, if it's a logical partition, as mine were. Then, reformat the partition, to erase the corrupted directories, and then restore the data from your Files and Folders archive. Boot drives present more complex hurdles, and cannot be restored fully using Files and Folders restore.

Of course, this does mean you'll need to have room to make that archive, and the time to do it. Since the restore process is now restoring files to their original location, this may even work in Boot Mode, though I did the restores in Windows. But, since the original file system has been erased, this might cause the same corruption to the file system on Boot mode restore.

Again, further testing is needed. Anyone else like to join in? Better to find out up front if something won't work on your system, than to wait until a hard drive fails to test the integrity of your restored data and file system.

 

Curt, for BartPE you have a couple of options. Check out http://www.reatogo.de/ and add the plugins you need plus get one of Mustang's plugins http://www.mechrest.com/plugins/
to add to it. You could also use http://ubcd4win.com/ and add one of Mustang's plugins. UBCD4WIN is a big download 133MB but includes numerous disk utilities and drivers.

 

Wow... thanks ThomasJK. More is better (I hope!). That gives me lots of things to try. All of which wouldn't be necessary if CHKDSK worked properly!

Working with BartPE right now, and I'll post again soon when I know more.

Christopher_NC -- you're right on the money when you say it's better to find out up front! I'm glad I'm working on one small text file instead of, say, system.dat!

Regarding restores of boot drives, I can add the following. I have had success with "files and folders" restores of a boot drive using the Windows-based application (from a live XP system where you are restoring the boot drive for another system attached as a second drive... not from the Rescue Media on the target system itself). You have to manually create the partitioin, mark it as "active" (do these things in XP's Disk Manager), and the it'd be a good idea to restore things in stages. I do a restore "C:\pagefile.sys" alone first, followed by another restore of "c:\*.*", then "c:\windows" (+subdirs), then "C\progra~1" (+subdirs), then everything else. While I haven't confirmed this with a sector editor, I'm inclined to believe this should put things back in more-or-less optimal locations. Of course, that assumes that none of your system files or directories were "corrupt and unreadable"! One other trick is the "System Volume Information" directory at the root of the drive, which is used by XP's "System Restore". If you turn off System Restore for that drive, then give yourself access to that directory, you can delete it and restore from your backup. If you don't do this, you will either not be able to access it (no permissions, by default) or Windows will continually re-create it and/or write into it as your restores are running. I was able to repair a problem with the Volume Boot Record of a drive by doing this. I believe this will recreate all of the NTFS data structures ($MFT, etc) as opposed to restoring them from your archive, so any prior corruption there (unless, potentially, it's ACL-related and you chose to restore security settings) should be fixed... well, not 'fixed' actually but worked-around.

So there are definitely ways around the problem, but I don't like the idea that an ostensibly 'mature' product like this should have such a basic problem.

I look at the rescue media like a life preserver on a ship. Except, in this case, it appears that one in a thousand of the life preservers on Acronis' ship is actually made of lead! Oh well...

I'll consider this exercise successful if we can find a way to un-do the problems that a "files and folders" restore from the Rescue Media creates.

It'll be wildly successful if we can get to the bottom of what the problem is with that "corrupt and unreadable" directory and actually fix it, then let Acronis know so they can fix the code they include with their rescue media.

Along those lines, here's my actual question (yes, there was one):

==> Does anyone have any good links to documentation on the internal structure of the NTFS file system? <==

I've looked at the stuff on linux-ntfs.org, which is pretty good, but not being a file system guru, I'm still trying to get my head around it. Some higher-level stuff would be helpful... Where I am right now is trying to figure out how you get from understanding where $MFT is located to translating that into the actual directory structure. The stuff at ntfs.com is a bit too high-level... it doesn't get down into the actual impementation details, nor does the stuff that MS puts out on Technet. Trying to get this done while with a full work day and family life is not the easiest, but what's a few more late nights, right?

Thanks, everyone, for the contributions.

-- Curt.

 

I am also having the same type of problem. I restored from the boot disk. It went to Drive(c), etc. and only the file in the lowest part of the directory structure was corrupted. I went through chkdsk /f /r and it saw nothing wrong. Deletion of the record has proved impossible - even with some tools out there that claim to help. I have tried Safe Mode, NTFS4DOS (which does not see the file).

I have seen the message "Cannot delete - The file or directory is corrupted and unreadable" more times than you can imagine as I have tried things like changing ownership, etc.

I hope someone finds a fix for this and will be monitoring this thread. Needless to say, I will also respoond if I find something.

This is very discouraging. I am a new convert to the product after seeing great reviews. However, file corruption is quite serious. It is already stopping my defragger. It also undermines my confidence in the product to recover successfully.

 

And thank you, Curt, for continuing to probe into the inner workings of TI Boot Mode searching for an answer to this elusive problem. Don't forget to take time off to spend with your family...we'll all survive even with a few corrupt directories.

You are likely looking at this already, but it occurs to me that what may be going on has to do with the naming conventions (forgive any blatent misuse of technical terms -- I'm not a coder) used by TI Boot mode when creating these new directories. Since the offending directories appear as Drive (H) or Drive (P), yet are not actually drives but new directories within an existing logical drive, could it be that TI is recording these directories in File Table code that is reserved for actual drives? Thereby inadvertently placing them in a superior (or at least non-functional) position to other folders on the drive? Apparently, the existing NTFS file system sees these orpaned directories and files, yet refuses to adopt them, or manage or delete them.

NTFS says, "That's not one of mine, you deal with them."

As your link to Microsoft support suggests, NTFS assumes that whatever program put them there can also remove them. So, Acronis, how about a tool that allows for the removal of these orphans? And, of course, solving their inadvertent corruption in a new build.

Backing up the data while excluding the corrupt directories is only practical on non-system drives. Another user started a thread today asking for help dealing with corrupt files on his system drive. (Corrupt file origin unknown, but, the same issue presents itself). https://www.wilderssecurity.com/showthread.php?p=833473#post833473
His backup process hangs, perhaps when it encounters the corrupt file(s). If he images the drive, he'd restore the corrupt file(s). Files and Folders won't restore a system drive. At least not in a way that's practical for most of us.

And, again, I would encourage those who are able to to test this on their systems. This may or may not be one life preserver in a thousand, as Curt put it so well. Acronis support will be more inclined to address issues if they are widespread. Are you able to restore data from Files and Folders backups to a new location using True Image 9.3677 Boot Mode? So far, we know of a few that aren't. Even though TI reports the operation as successful.

If you do conduct a test, please restore to a data partition, not to your system drive, unless you are prepared to restore it with an intact image. Of course, the less data you have on the partition, the less you will need to restore. So, you could create a small test partition, formatted NTFS, for this experiement. Just don't follow John Gallagher, and find out how tough it is to delete these corrupt directories once they occur.

 

Hi Curt,

Good luck with your trouble shooting. You may discover a few parts of the puzzle in the technical area of <Dan Goodell's web site> (it's a goldmine of technical know-how), including the "Links to More Information" and "Miscellaneous Notes".

Regards

 

*** SUCCESS!!! ***

I have been able to remove a directory which Windows Explorer reports as "corrupt and unreadable"!

In brief, the problem seems to occur when a "files or folders" restore (as opposed to a "disks or partitions") is performed from the Rescue Media (as opposed to running natively real XP), and possibly only when restoring to a "New Location" (as opposed to the original location). The restore operation will run and complete with a message that it was successful. However, you may experience the problem described below.

The main symptom is that, when navigating to the lowest-level directory in the directory tree that is restored, when Explorer attempts to open, delete or move that directory (say, to view the files in that directory that were supposed to be restored), Explorer will display the message "File or Directory is corrupt and unreadable." From a command prompt, you will get a 'pop-up' in the taskbar with a similar message if you try to 'cd' or 'rmdir' the directory.

For example, I had a file called "C:\Documents and Settings\%userprofile%\Desktop\temp3.txt". ('%userprofile%' stands for XP logon ID.) The file was backed up as part of a drive-image (not a sector-by-sector... just regular image) backup, and then I tried restoring it to a different location. The location I chose was "C:\Documents and Settings\%userprofile%\Desktop", so TI created the path "C:\Documents and Settings\%userprofile%\Desktop\Drive(C)\Documents and Settings\%userprofile%\Desktop\" and should have restored the file "temp3.txt" under that.

(I know the path is long, but that's not the issue... trust me. Christopher_NC had the issue restoring a file at the root of the drive, and the file he couldn't restore was in "\Drive(C)"... can't get much shorter pathname than that.)

Anyway, trying to explore or delete "C:\Documents and Settings\%userprofile%\Desktop\Drive(C)\Documents and Settings\%userprofile%\Desktop\" produced the errror.

Now for the fix.

*** DISCLAIMERS ***

(A) I make no guarantees that this will work in all cases. In fact, there is a real chance of SEVERE DAMAGE TO THE ABILITY TO ACCESS DATA if something goes wrong. All I know is that it worked once for me. If you try this, DO SO AT YOUR OWN RISK. I am not responsible for any consequences resulting from reliance on the information in this post. (i.e., don't do this on your un-backed-up boot drive of your only PC.)

(B) This is not for the feint of heart. You have to be comfortable with Linux to pull this off... at least comfortable enough to know how to mount filesystems, for example.

(C) I haven't confirmed that there are not latent problems resulting from the fix... I'm working on that, but I'll never be 100% sure... 99% is the best I can hope for.

(D) Ultimately, the only real fix will have to come from Acronis. This posting is simply to share my experiences, help Acronis deliver an official fix by providing supplemental information, and satisfy the curious / desperate folks reading this thread.

OK. Enough legalese.


*** THE FIX ***

In short, I used the Trinity Rescue Kit and the included FUSE NTFS filesystem driver to ‘rm’ the affected directory.

Per the author, “Trinity Rescue Kit 3.1 or TRK 3.1 is a 100% free CD bootable Linux distribution (live cd) aimed specifically at offline operations for Windows and Linux systems such as rescue, repair, password resets and cloning, with the ability to update itself . “ See http://trinityhome.org/Home/index.php?wpid=1&front_id=12.

I downloaded TRK 3.1, Build 2.10 (specifically, trinity-rescue-kit.3.1-build-210.iso), and burned that to a CD-RW, and booted from the image.

I tried the TRK ‘mountallfs’ script, no arguments, which mounts all the file systems it can recognize. (If I weren’t lazy, I would have looked up the proper arguments to ‘mount’ myself, but when someone is nice enough to provide a script… hey. In retrospect, I would have had an easier time if I *had* taken the time, because then I’d have know whether FUSE was in the base TRK image or if I had to update, but that’s all water under the bridge…)

Anyway, the script mounted my affected NTFS drive, but navigating to the affected directory and trying to ‘rm’ it didn’t work. That’s because it was using Linux’s native NTFS filesystem driver, which, as it turns out, has mostly (with small exceptions) read-only capabilities. As I was focused on the Captive solution, I proceeded as below. (Also, as a sidebar, I had posted earlier that TRK includes the linux-NTFS filesystem driver… that’s not accurate. The author has had great initial success with that driver, but has not rolled it into the current release as of the date of this posting.)

As mentioned above, TRK includes a “self-updating” feature. I ran this because it referenced the ability to download components necessary to load the Captive NTFS drivers. Whether it’s strictly necessary to do this update, I’m not sure. But I did it and it worked, so that’s what I’ll document here. You might not need to go through this, but without further investigation, I can’t be sure. I actually didn’t use the Captive filesystem… it did NOT work to remove the affected file. That’s probably because it uses Windows drivers. What worked was the FUSE filsystem. I’m just not sure whether the “un-updated” version of TRK has FUSE support enabled / configured or if perhaps the updater script enabled / changed it in some way. So I’ll just document what worked for me and if there are any shortcuts that folks find, feel free to post them.

So back to the updating script. From the shell prompt (“#”), I typed ‘updatertk’ (no quotes… all my commands will be in single-quotes.) with no arguments. This automatically went out and did a lot of things. However, when it got to the parts about locating the proper Windows drivers for Captive NTFS on my boot drive, I skipped those parts (mostly hitting <ENTER> to skip, I think), until it went out to Microsoft and got them from the latest SP2 distribution.

At that point, it created a new ISO image for itself and put it in my “C:\Temp” directory. I happened to have that directory already… don’t know if it would have put the image somewhere else if I hadn’t but it tells you where it thinks it put it as the script exits.

I then booted back to Windows to see if the image was there (it was), and I burned that to a CD-RW. I suppose I could have used ‘cdrecord’ from within the shell, but I was curious. Again, just documenting what I did… not necessarily every possible way to do things.

At that point, I rebooted with the *updated* TRK CD.

From the shell prompt, I typed ‘mountallfs -c’, which successfully mounted the affected drive, this time with the Captive drivers. I then navigated to the affected directory and tried to ‘rm’ it. Again, no luck.

I then started searching the forums at the TRK website and came across a very relevant post which suggested using the FUSE filesystem drivers instead of Captive NTFS.

So, I ran the ‘umountallfs’ script, which unmounted my affected drive, then ran ‘mountallfs -f', which re-mounted it, this time using FUSE.

I navigated to the affected directory and viola! Success! I was able to ‘rm -d’ (or ‘rmdir’, I forget) it.

Booting back into Windows, the affected directory was gone and Explorer was able to remove all the parent directories that TI had created.

I believe the FUSE worked because it’s a native (albeit in userspace) implementation of an NTFS filesystem driver, basically written from scratch. The Captive NTFS approach is to wrap some Microsoft drivers. A great approach for compatibility, but in this case we didn’t want compatibility. That’s probably why BartPE doesn’t help, either.

So in summary, what I did was:

1/ Download TRK 3.1 Build 210
2/ Update TRK via the ‘updatetrk’ script, allowing it to get the necessary Windows drivers for Captive NTFS from Microsoft (probably not necessary, but not sure)
3/ Ran ‘mountallfs -f' to mount my affected drive with the FUSE driver
4/ Navigated to the affected directory and removed it with either ‘rm -d’ or ‘rmdir’.

NOTE: Apparently, the FUSE drivers have some limitations on the number and size of things they can work with, so this might not work for everyone and could potentially cause damage! Beware! Remember, we’re talking about someone’s open-source code writing to the heart of NTFS’s internal data structures. This probably worked for me because it was only one directory that was affected. Your mileage may vary, especially as you approach boundary conditions. Once again, proceed at your own peril.

That’s about it.

I’m going to continue to investigate the root cause, and if I find out anything, I’ll post back.

Again, if anyone has good references for the internals of NTFS (aside from linux-ntfs.org, ntfs.com an Microsoft), let me know.

I’ll also come back with a posting to Acronis regarding their handling of the issue. But that’s another story, too.

Hope this is interesting reading to everyone… good luck, and enjoy!

-- Curt.

 

Curt -

I am willing to try this method to delete but am not a Linux guy. Could you describe the commands necessary after the mount to "navigate" to the directory and remove it?

Something tells me Acronis is not going to be able to help and this might be worth a shot before a reformat and restore.

Thanks.

John

 

John,

Just now, I tried a fix that might work for you. If you overwrite the corrupt files 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. It did yeild files I could open, but the directory structure was not overwritten, or repaired. 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 one. If at first you get this result, try again. Once overwritten by the Windows version of Files & Folders (which seems to be able to handle this task correctly) your errors should be gone.

I hope this helps.

 

Actually, I just finished following Curt's advice earlier in the thread. I admit to knowing little about Linux but, between his instructions and a one page Command Reference that I found somewhere (Don't ask me where as I got it, printed it and lost track of the site), I was able to mount TRK, get to the file in question and remove it. I am now back in Windows XP and have deleted the directory structure above the file without incident.

The bottom line: TRK does the job! (Incidentally, I did not need to do the update to TRK.)

For those brave souls out there, learn a little (very little) Linux and you can do it too.

As a footnote, I agree with Curt and others: it is great that we can fix (crossed fingers) the problem without damaging something else; Acronis still has to step up and 1.) admit to this problem and 2.) provide an expedited fix to their software.

 

Hello Christopher_NC and cequi,

Could you please collect the file based backup archive that restore the files that claims as corrupted then submit a request for technical support and indicate in the subject that you would like to contact Ivan Belinsky? Attach the collected file and the link to this thread. We will investigate the problem and try to provide you with the solution.

Thank you.
--
Aleksandr Isakov

 

Hello everyone,

Please disregard Aleksandr's reply. I've just consulted with the respective person from our Quality Assurance Team regarding this issue and it appears that, as Curt has already mentioned above, the problem is caused by the fact that under some circumstances Acronis True Image creates folders on NTFS partitions somehow incorrectly when it is operating in Linux-based rescue environment. In other words, it is most likely a question of NTFS driver. Whatever the actual reason is, our Quality Assurance Team is aware of this issue and will proceed with the investigation. I'll inform you about the results as soon as their investigation will be finished. I'll also let you know if some additional information is required.

P.S. Curt and Christopher, your detailed investigation and kind attempts to help us in resolving the issue are very much appreciated. At least, we know how to remove the problematic folders now. I believe the reason will be found and eliminated soon as well.

Thank you.
--
Alexey Popov

 

Alexey,

Thank you!!! I am thrilled to read a public acknowledgement of this issue. My confidence in Acronis is strengthened by your candor.

I am also pleased to know that Acronis is working on a resolution. Yes, please do keep us informed. Since the issue seems to appear on various hardware configurations, your team will likely find and resolve the issue on their own. If you need any further information to assist your investigation, I have been keeping copies of each SnapAPI log with details of each operation resulting in corrupt directories, and would be happy to furnish them to you.

Good to know we are working together to make this fine program even better!

 

Just like to add that I am also experiencing this problem. Unfortunately, it happened to my boot drive, which I've just spent the past two weeks reinstalling programs and restoring data because when I tried to restore the whole drive Windows wouldn't boot.

I haven't tried restoring the bad files from within Windows yet (at least, I don't think I have), but I will. So far, I've identifed 5 files out of approximately 121,000 that are bad. Fortunately, none of them are critical. But does anyone know of a tool that can scan the drive and identify all of them? I'm worried that there are files which appear to be ok but won't be until I try and access them. In fact, it was just luck that I stumbled onto three of them; the others I found when I moved all of the other files in the directory to a new directory; two of them wouldn't move.

I sure hope True Image fixes this soon. As a new customer, I'm a bit disappointed, to say the least. Hopefully, if the restore from within Windows doesn't fix the problem, Acronis will come up with a tool that will. Recovering the files would be ideal, but at least let me delete them!

 

Since a picture is worth a thousand words (unless one is a writer), here's a screen shot that may help show one way this problem manifests:

As ddi points out, finding the corrupt files is hit and miss. Of dozens of .jpg images I checked in a corrupt directory made using TI Full Boot Mode Files and Folders restore, to a new location, I found 3 images that had horizontal banding or large sections rendered dark, or the colors changed.

Checksum confirms what you see, that the TI restored photograph on the left, in Drive (O)...DSC_3151.jpg, is not identical to the original in I:\ My Pictures...DSC_3151.jpg on the right.

I also checked several large program.exe files, in the restored Drive (O) directory, which were corrupt, and would not install.

The free version of Checksum I use works manually on a file-by-file basis. I haven't used the paid version, but just checked the IRNIS site, and their Advanced CheckSum Verifier (ACSV) v1.5.0 sounds like it will check batches of files. http://www.irnis.net

Again, for now, my workaround is to not restore files and folders to a new location using TI Full Boot Mode.

 

I tried restoring the corrupted files from Windows, but True Image said that it had to reboot. I allowed that; after chkdsk ran, True Image ran and displayed messages about analyzing partitions; then it said something like "Error: disk not found" and rebooted. It came back to that same blue screen and put up a message saying something about True Image completed. Then Windows came up. When I looked in the directory with the corrupt files (and to which I had tried to restore one of the corrupt files), there was a new copy of the file I had tried to restore but with some random characters on the end of the filename. I was able to delete that file, but of course the corrupted files remain.

I would really like to delete those files without having to reformat and reinstall everything. Is there no tool or procedure that can do that? I'm considering trying to use BartPE to build a standalone Windows CD. I've tried using Knoppix but it couldn't access the disk and I don't know how to mount an NTFS volume (I thought it would automatically recognize and mount it). At any rate it sounds like the captive-ntfs "driver" just uses the Windows drivers so it probably won't let me access the files either. I would even consider using something like Acronis' Disk Editor to zap the file entries in the MFT, but I'd need pretty explicit instructions since I'm not very familiar with the NTFS file structures.

 

Hello everyone,

According to the results of our investigation, it seems that the issue only appears with particular types of files and folders, though it is not clear yet with which types exactly.

Could you please provide us with the examples of the files\folders that became corrupted after they were restored from the disk\partition images using the Bootable Rescue CD?

Thank you.
--
Alexey Popov

 

I had five file corrupted: four .exe's and one .zip. All of the .exe's are self-extracting archives. (It was my Downloads directory that contained the corrupted files; I restored it first so that I could reinstall True Image. Ironic, huh?) Three of the .exe's are large, 12-18 MB. One is tiny, 166 KB. The zip file is 1 MB.