Member Avatar for richh0323
richh0323 0 Junior Poster in Training

Ok here goes the problem, I have a computer with XP Pro on it 2 drives are
SATA 250 gig formatted NFTS and they are the boot drives, I also have a 160 gig IDE Maxtor 6Y160PO, that was FAT32 format and a Fujitsu MPB3064ATU 6.1 gig FAT32 drive. The 160 gig drive had 6 years of backups on it (it's a new drive) from my old systems. I was redoing a old system and I removed the 6.1 gig
Fujitsu drive to work on the older system and had changed the jumper to
master. The drive was a bootable 98 drive for the old system. When I reinstalled this drive in my new system I forget switch back the jumper to slave. This drive is on my secondary IDE drives, the SATA drives are my primary boot. I realized my mistake, I shut down the system normally and then changing the jumper to slave. When I rebooted a blue screen came up and Windows file check was running, I couldn't stop it. Now the 160 gig Maxtor is reporting back that it is a 6.1 gig fat32 drive. I have one folder in it named FOUND.000 and files that are named FILE0000.chk to File9999.chk. I called Microsoft and they gave me the canned response you must of shut down your computer wrong.
I work with computer systems all the time, so I'm not a dummy, but
not a programmer. Any ideas how to reverse the process that check disk did,
or recover data on this drive? Any help is appreciated. I downloaded Stellar Phoenix data recovery software to one of my SATA drives and I can see the files are still there, but can't see them with explorer. By the way the BIOS reports the drive is a 160 gig drive.

Rich

  • 1 Contributor
  • 0 Replies
  • 116 Views

Dani AI

Generated

The FOUND.000 folder and a pile of FILExxxx.CHK entries usually mean the disk-check utility found orphaned clusters and wrote them out as raw fragments. That is not necessarily total loss — the file contents often remain — but further writes make recovery harder. Do not run more repairs or copy anything to the affected drive. First action: make a sector-level image of the drive and work from that image.

Image the disk read-only to another physical drive (use a USB/IDE adapter or attach it as a secondary). Use a trusted imaging tool that preserves every sector and can verify checksums (examples include forensic dd variants or imaging utilities). Verify the image after creation so you can repeat recovery attempts safely without touching the original hardware.

Try to restore metadata first, then carve what remains. TestDisk can rebuild FAT/FAT32 directory and FAT structures (run its analysis in read-only mode at first). If that fails, use a signature-based carver such as PhotoRec to extract files from the image — it ignores the filesystem and often recovers documents and images by type. Because already reports a commercial scanner could “see” files, that strongly suggests the data blocks are present; imaging plus TestDisk/PhotoRec often recovers most user files. If filenames and folder structure are essential, look for tools that attempt to recognise and rename .CHK contents, or inspect a few .CHK files in a hex viewer to identify file headers before bulk renaming.

Avoid re-running chkdsk, formatting, or installing recovery tools onto the affected disk. If recovery from the image fails or the data is business-critical, a specialist data‑recovery lab that works from images is the safest next step.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.