Files not recoverable on the second scan!
#1 OFFLINE
Posted 14 July 2012 - 12:41 AM
1) This drive was not used after I moved the files off of it except for these attempted recoveries.
2) Since I was just scanning and recovering, the files could not have been altered, could they?
The only thing that makes sense is Windows totally screwed me with its forced update shut down, resulting in a ton of cross-linked files. My other drives did not seem to experience this.
So is there any way to get out of this? Would it be wise to run Chkdsk on the drive? Does Chkdsk ever successfully repair crosslinked files? Wouldn't it fail to do anything helpful to my deleted/moved files from a Chkdsk, since Chkdsk sees the files are reported moved/deleted?
If I just would have let the recovery go to the end, I would have had all the files healthy, albeit 8,000 of them in a single directory. It drives me nuts.
Any help welcome. Please.
#2 OFFLINE
Posted 14 July 2012 - 03:21 AM
Half the time I am not disappointed
That is why updates are fully blocked on my machine until I choose to let them happen.
I only expect update damage to happen on C:\,
I would not expect it to damage other partitions.
dadarkda, on 14 July 2012 - 12:41 AM, said:
Quote
If you are recovering to the same partition that you are scanning then you are over-writing the files that have yet to be recovered,
and the first 4000 files you recovered could have over-written the remainder.
I suggest you identify your version of Windows, and 32 bit or 64 bit,
and the size of and format of the partition(s) you were scanning and saving files to.
#3 OFFLINE
Posted 14 July 2012 - 12:14 PM
Alan_B, on 14 July 2012 - 03:21 AM, said:
If you are recovering to the same partition that you are scanning then you are over-writing the files that have yet to be recovered,
and the first 4000 files you recovered could have over-written the remainder.
I suggest you identify your version of Windows, and 32 bit or 64 bit,
and the size of and format of the partition(s) you were scanning and saving files to.
Thanks for your reply Alan,
I'm on W7 64-bit, I'm dumping to a 3TB Caviar Green, healthy. The drive I'm dumping is some WD Caviar 250GB SATA. I've learned never to recover to the damaged drive, so that didn't happen. I FOOLISHLY failed to explain in my first post that this drive has pending and uncorrectable sectors, which is why the files were moved off the drive months ago. Now, the drive I moved these files onto is failing! Pretty bad luck. I don't know though how from one scan and reboot, a failing drive can go from recovering 8,000 files perfectly to recovering only half of them correctly due to crosslinked files. Should I chkdsk /v /x /r on the drive, move the crosslinked files, then delete them to try to repair the file allocation table? I'm afraid that may make things worse, but I don't know.
Speedfan Report:
BLOCKING ISSUE : your hard disk has 313 pending sectors (this value is very large and your hard disk should be replaced). Those are sectors that couldn't be properly read and that the hard disk logic is waiting for a write operation to try to remap to a spare sector (if available). According to the Reallocated Sector Count attribute, your hard disk seems to have available spare sectors. A simple disk surface scan won't be enough to force the remap operation. You need a read/write surface scan to remap the sector. The best option should be a tool that knows about what should be read from that sector so that it has some option to apply the best fix to the missing data.
BLOCKING ISSUE : your hard disk has 276 offline uncorrectable sectors (this value is very large and your hard disk should be replaced). Those are sectors that an offline scanning found as unreadable. Offline scanning is a process that can be automatically started by the hard disk logic when a long enough idle period is detected or that can be forced by some tool. Those unreadable sectors are identified and the hard disk logic is waiting for a write command that will overwrite them to try to remap them to spare sectors (if available). According to the Reallocated Sector Count attribute, your hard disk seems to have available spare sectors. A simple disk surface scan won't be enough to force the remap operation. You need a read/write surface scan to remap the sector. The best option should be a tool that knows about what should be read from that sector so that it has some option to apply the best fix to the missing data.
#4 OFFLINE
Posted 14 July 2012 - 02:31 PM
There are others on this forum who can take it from here.
Alan
#5 OFFLINE
Posted 14 July 2012 - 04:12 PM
Before beginning system restore, disconnect your internet connection so the update won't be re-downloaded & ruin your recovery process all over again.
After System Restore has finished & rebooted your PC back into Windows, reconnect your drives, & attempt recovery again.
This is by no means guaranteed to fix your problems, but it may be worth a try, as Windows Updates can indeed cause problems.
#6 OFFLINE
Posted 15 July 2012 - 12:45 AM
If some kind of file transfer was going on at the time between Recuva and your dodgy drive then some kind of cross contamination could indeed have occurred.
Each time your bad drive is accessed now reduces the chances of recovery.
Perhaps firing up a linux cd and browsing to them with that and copying them to your good drive may give you another option to consider.
http://www.piriform.com/docs
#7 OFFLINE
Posted 15 July 2012 - 02:25 PM
1) Computer loses power during update/reboot cycle before the patch is fully downloaded or applied. Something goes wrong, kaplooey!
2) Bad update (incomplete update on server, bad update patch... Sometimes a mirror server will have an incomplete update)
3) Bad driver update (Windows installs incorrect driver for your hardware)
Although things like this are not common, they are not non-existent either.
Today, as I was clean installing 64 Bit 7 to a PC with built-in wifi, W7 64 Bit DID install a driver for the wifi connection, but it would not accept my router password till I updated it to the correct driver for the built-in wifi. W7 installed a driver, yes, but it was a non-functioning one. Usually, W7 does a good job of detecting hardware & installing the right driver or update, but occasionally, it makes a boo boo.
And it certainly did on the PC I was working on today. No biggie. After I installed the correct driver, it took the password.
It is entirely possible that it may have been Windows Update (or something interrupted during update), just as it is also possible that it may have been something else.
* The linux (Ubuntu, perhaps?) live disk is a great idea, if your files are visible to the OS. If they are "deleted" as Windows sees them, you probably will still have to attempt recovery from within a Windows environment. I don't believe that Recuva runs from linux, but I may be incorrect.
#8 OFFLINE
Posted 15 July 2012 - 03:05 PM
I was talking about the fact that Windows Updates had done nothing wrong in this instance as it was rebooting to update its system files.
Recuva can be run from Hirens.
http://www.piriform.com/docs
#9 OFFLINE
Posted 15 July 2012 - 03:15 PM
You are supposing that nothing was wrong with updates because it was rebooting to update its system files.
I merely suggested that Windows has a few ways it can go wrong, of the which one of them is a bad driver update.
I had it happen to a PC I was working on today, which is why I suggested that it could, indeed, still be Windows Update problem because of a bad driver.
I am not suggesting that this is the problem, merely that it is a possibility as it can/does/did happen today with me. After which I fixed it with the correct driver.
Just because a PC is rebooting after a Windows Update does not eliminate the possibility that Windows Update is the culprit. It may not be, but it also still may be.
I have not used Hiren's, though I believe I have a copy downloaded somewhere.
Might be worth checking out.
#10 OFFLINE
Posted 17 July 2012 - 12:53 PM
hazelnut, on 15 July 2012 - 12:45 AM, said:
What advantage in recovery might the linux environment offer, if any, when it comes to "Recuva-marked Unrecoverable/Crosslinked" files? Is it possible that there is another way a recovery program can look at the data and see a way to extract those types of files correctly? Have you had files in one recovery program report "crosslinked" or "unrecoverable," to have a different recovery program recover the file successfully?
Thank you for everyone who's replied; I don't have the money to spend $1,000 for recovery, and I'm thinking that if recovery software keeps reporting these certain files as crosslinked that a recovery expert may not be able to get anywhere anyway. I've heard of data carving, but I would assume someone who can do that probably costs a small fortune. I might be wrong though.
#11 OFFLINE
Posted 17 July 2012 - 09:56 PM
dadarkda, on 17 July 2012 - 12:53 PM, said:
Have you tried the possibility of running System Restore to a prior date when things were working? I would ensure all my important files are backed up first.
This might not fix the problem, but if it does, it will save a lot of time & effort...
#12 OFFLINE
Posted 18 July 2012 - 12:09 AM
DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF.
Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark)
ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T.
CCLEANER, RECUVA, DEFRAGGLER AND SPECCY DOCUMENTATION CAN BE FOUND AT www.piriform.com/docs
Link to Winapp2.ini explanation
#13 OFFLINE
Posted 18 July 2012 - 05:01 PM
Nergal, on 18 July 2012 - 12:09 AM, said:
Not denying the writing part. Just wondering if he suffered MFT damage that System Restore could repair, possibly eliminating the "cross-linked" file problems?
#14 OFFLINE
Posted 19 July 2012 - 02:22 AM
The impression I have is that we are NOT discussing cross-linked files on the main System partition, NTFS with MFT,
but a non-system partition that is possibly FAT32 with FAT tables and probably on a separate HDD.
Regardless of the partition format,
System Restore is intended to restore the system, focusing on a permanent system Partition C:\.
If the problem is with a drive that gets removed / swapped and might even be external via ESATA cable,
then System Restore could be irrelevant.
#15 OFFLINE
Posted 19 July 2012 - 03:23 AM
If you mean that two live files in the MFT point to the same cluster then the MFT is corrupted and, even if it can be fixed, one set of files will be lost forever. I don't know how this could happen easily, as NTFS goes to great pains to ensure the integrity of the MFT.
If you mean that an attempt to recover deleted files has found that some of these files have been overwritten by new live files then this is normal activity: the overwritten deleted files are lost forever.
#16 OFFLINE
Posted 02 August 2012 - 11:41 PM
Augeas, on 19 July 2012 - 03:23 AM, said:
Sometimes, the simplest ways are the ones that bring a system down.
1) Create a new empty folder.
2) Copy a CCleaner icon to the folder & name it icon.ico.
3) Once you have experimented with different thumbnail views, delete icon.ico that displayed the CCleaner icon.
4) Copy a Defraggler icon to the folder & rename it to icon.ico & you will see it take on the appearance of the former CCleaner icon.ico that was there earlier.
If not, just play with the different thumbnail view settings & you will see this effect for some of the thumbnail instances.
Windows creates a hidden thumbnail.db database that is not always updated as it should be, which will be self evident if you follow the instructions above.
Because you formerly had icon.ico in the folder (& it was a ccleaner icon) & now you have deleted it & added a Defraggler icon that is named icon.ico, Windows gets confused & thinks it is still looking at the same icon it was using earlier.
Thus, even though it correctly shows the new Defraggler icon when you open it in an image viewer, it still retains the former CCleaner icon.ico cache.
Simple "misunderstandings" like this compromise data integrity over time. I can only imagine that the MFT suffers from similar problems as Windows.
#17 OFFLINE
Posted 03 August 2012 - 12:10 AM
But the table of contents has a mistake, it says chapter 8 begins on page 100 and also that chapter 9 begins on page 102. And maybe even that chapter 10 begins on page 101.
So we have multiple file entries registered to parts one file. And it could be the wrong file to boot!
Yes, NTFS does go to great pains to keep things organized and correct. The most common thing I see that messes up NTFS is intermittent memory problems or incorrect power down or crashed applications.
#18 OFFLINE
Posted 03 August 2012 - 01:19 AM
Can we hold all discussion until he replies again in the thread.
http://www.piriform.com/docs










