NTFS Repair software

B

botboy

2[H]4U
Joined
Mar 21, 2000
Messages
2,680
Aww nuts...I mean....aww nuts....

I have attached to my laptop, a 250 gig western drive inside an acomdata case, which I use for backups and storing my MP3 collection, which is rather large.

So anyway, a friend of mine that I tend to swap files with a lot, is home this weekend so we drop my drive in his computer, start some files transferring, and go off to run some other errands and get food, etc. So I come back, his computer apparently locked up in the middle of transferring files, so I shut it off, pull the drive, put it back in the external case and attach to my laptop, well the drives file system got fucked, restarting winXP got Chkdsk running, which reported that the file structure had received some repair and then went thru a huge list of files with orphaned portions that were being put back together. I figure alls well that ends well...then I start winamp

A bunch of my MP3's are completely fucked, including ones I have legally (own the CD or downloaded after paying for) which makes me very, very not-happy. Some the length won't even show up when winamp is going down the list, others just click and pop when played and make random noises that aren't music, files that I know previous to the crash were good.

Obviously chkdsk didn't properly repair them or the other computer locking up messed them up beyond chkdsk's repair...anyway, I would like to know if anyone here has any recommendations for software to attempt to fix this....I really don't like the prospect of re-downloading or re-ripping over 2500 damaged files. Some I do have backups for, hopefully I can restore most of them, but if I could restore all of them in one fell swoop it would be preferred.
 
1. HDDs arent media, they are very fragile
I know they sell them with the promise of portability, but it aint all that great an idea
especially without full backups

2. Filesystem Corruption and an automatic rebuild of the metadata with chkdsk can often be destructive, the MFT can be either a pointer to or the data itself, depending

3. While a direct scan of the sectors might uncover some of the data in a usable form, that wasnt automatically recovered or more accurately discarded, youll have alot of fun verifying each file, and you will need someplace to write it to.

4. Most of the time when you talk about repair, its the reconstruction of the MBR or Partition Table not the MFT
now I havent used this, but it might be exactly what your looking for CHK-Mate 1.0 CHK File analysis and repair, which will convert .CHK files to their proper extentions

5. Corruption 101 > Filesystem > An Explanation of CHKDSK and the New /C and /I Switches

<MORE

"To understand when it might be appropriate to use these switches (/C and /I) , it is important to have a basic understanding of some of the internal NTFS data structures, the kinds of corruption that can take place, what actions CHKDSK takes when it verifies a volume, and what the potential consequences are in circumventing CHKDSK's usual verification steps.

CHKDSK's activity is split into three major "passes" during which it examines all the "metadata" on the volume and an optional fourth pass. Metadata is "data about data." It is the file system overhead, so to speak, that is used to keep track of everything about all of the files on the volume. Metadata tells what allocation units make up the data for a given file, what allocation units are free, what allocation units contain bad sectors, and so on. The "contents" of a file, on the other hand, is termed "user data." NTFS protects its metadata through the use of a transaction log. User data is not so protected.

During its first pass, CHKDSK displays a message on the screen saying that it is verifying files and counts from 0 to 100 percent complete. During this phase, CHKDSK examines each file record segment (FRS) in the volume's master file table (MFT). Every file and directory on an NTFS volume is uniquely identified by a specific FRS in the MFT and the percent complete that CHKDSK displays during this phase is the percent of the MFT that has been verified. During this pass, CHKDSK examines each FRS for internal consistency and builds two bitmaps, one representing what FRSs are in use, and the other representing what clusters on the volume are in use. At the end of this phase, CHKDSK knows what space is in use and what space is available both within the MFT and on the volume as a whole. NTFS keeps track of this information in bitmaps of its own that are stored on the disk allowing CHKDSK to compare its results with NTFS's stored bitmaps. If there are discrepancies, they are noted in CHKDSK's output. For example, if an FRS that had been in use is found to be corrupted, the disk clusters formerly associated with that FRS will end up being marked as available in CHKDSK's bitmap, but will be marked as being "in use" according to NTFS's bitmap.

During its second pass, CHKDSK displays a message on the screen saying that it is verifying indexes and counts from 0 to 100 percent complete a second time. During this phase, CHKDSK examines each of the indexes on the volume. Indexes are essentially NTFS directories and the percent complete that CHKDSK displays during this phase is the percent of the total number of directories on the volume that have to be checked. During this pass, CHKDSK examines each directory on the volume for internal consistency and also verifies that every file and directory represented by an FRS in the MFT is referenced by at least one directory. It also confirms that every file or subdirectory referenced in each directory actually exists as a valid FRS in the MFT and checks for circular directory references. Finally, it confirms that the various time stamps and file size information associated with files are all up-to-date in the directory listings for those files. At the end of this phase, CHKDSK has ensured that there are no "orphaned" files and that all the directory listings are for legitimate files. An orphaned file is one for which a legitimate FRS exists, but which is not listed in any directory. When an orphaned file is found, it can often be restored to its rightful directory, provided that directory is still around. If the directory that should hold the file no longer exists, CHKDSK will create a directory in the root directory and place the file there. If directory listings are found that reference FRSs that are no longer in use or that are in use but do not correspond to the file listed in the directory, the directory entry is simply removed.

During its third pass, CHKDSK displays a message on the screen saying that it is verifying security descriptors and counts from 0 to 100 percent complete a third time. During this phase, CHKDSK examines each of the security descriptors associated with each of the files and directories on the volume. Security descriptors contain information regarding the owner of the file or directory, NTFS permission for the file or directory, and auditing information for the file or directory. The percent complete in this case is the percent of the number of files and directories on the volume. CHKDSK verifies that each security descriptor structure is well formed and internally consistent. It does not verify that the listed users or groups actually exist or that the permissions granted are in any way appropriate.

The fourth pass of CHKDSK is only invoked if the /R switch is used. /R is used to locate bad sectors in the volume's free space. When /R is used, CHKDSK attempts to read every sector on the volume to confirm that the sector is usable. Sectors associated with metadata are read during the natural course of running CHKDSK even when /R is not used. Sectors associated with user data are read during earlier phases of CHKDSK provided /R is specified. When an unreadable sector is located, NTFS will add the cluster containing that sector to its list of bad clusters and, if the cluster was in use, allocate a new cluster to do the job of the old. If a fault tolerant disk driver is being used, data is recovered and written to the newly allocated cluster. Otherwise, the new cluster is filled with a pattern of 0xFF bytes. When NTFS encounters unreadable sectors during the course of normal operation, it will also remap them in the same way. Thus, the /R switch is usually not essential, but it can be used as a convenient mechanism for scanning the entire volume if a disk is suspected of having bad sectors.

The preceding paragraphs give only the broadest outline of what CHKDSK is actually doing to verify the integrity of an NTFS volume. There are many specific checks made during each pass and several quick checks between passes that have not been mentioned. Instead, this is simply an outline to the more important facets of CHKDSK activity as a basis for the following discussion regarding the time required to run CHKDSK and the impact of the new switches provided in SP4"

MORE>


Description of Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000


6. Intial cause of the corruption is also an issue, especially if it was head slap
(back to first link)
Head slap is when the actuator arm/read-write assembly impacts the platter due to a shock such as a tip-over, a tap with a screwdriver, or an overly aggressive shove to get the drive into a bay. This can also occur if you try to scoot the box across your desk while it is running.

As a result of the impact, tiny indentations can be formed. The material ejected from this impact is scattered about the disc, and when the drive is powered up the heads will pass over this indentation and the ejected material. This can be the equivalent of running over a bowling ball in a go-cart traveling at Mach 813.
Click to expand...



you have a bit of work ahead of you Good Luck ;)
 
I'm careful with the drive, I understand that its pretty fragile and thus take care of it well. i had no problems with it prior to the friends computer crashing, and chkdsk did repair the file system enough so that i could actually access the drive....before, firing up disk management showed the drive as "healthy" but there was a blank where there was once an "NTFS" for that drive. After chkdsk it fixed that, I can read the drive and windows management shows the filesystem for the drive as NTFS, I just have a large number of files with corruption. Researching programs shows that GRC (Gibson research corp) just released a new version of spinrite, one that reads and repairs NTFS partitions. I'm going to try that and see how it goes.
 
Ice Czar said:
http://grcsucks.com/spinrite.htm

personally I wouldnt let Spinrite with ten yards of my disks
you should really review DIY DataRecovery's CHKMate
but its your data
Click to expand...


Every fat and fat32 drive I've turned spinrite 5 loose on fixed everything up right and proper. I'll let results speak to me, but I'll definitely give chkmate a try before spinrite (since it would mean no use of the drive for at least a day and a half).

As far as the website, most data recovery places use some sort of "black magic" to advertise that it can't be done by the average individual with readily available programs, and to a point, that is correct. My problem with the website is that if spinrite is actually as shitty as he claims, then what the hell should I buy that is better? That's like the idiots who walk around campus (I'm at Iowa state u right now) preaching about how shitty the *insert political figure here* does his job, yet offer no better solution, and refuse to get involved in repairing said political system.
 
Chkdsk didn't create any .chk files in its repair process, so I'm out of luck with chk-mate :( Problem still seems to be lying in the orphan file segments, although I'm unsure how to go about repairing the problem. If all else fails about 80% of the files can likely be restored from a recent backup, but it still leaves about 1500 files I will need to re-download, re-rip etc. This sucks.
 
You must log in or register to reply here.
Back
Top