recuperation wrote: ↑23 Jan 2024, 01:41
The extended LBA partition is an extension of the old MS-DOS partition table allowing for multiple partitions on a disk. The original MBR scheme just contained one partition table with four entries. One of the four entries was marked "active" and was the only visible one. The extended (LBA) partition contains so-called "logical partitions". That scheme does not relate to what is inside of a partition. The content could be raw or any file system possible.
I had a rough understanding of this way, way back, but it's all a bit fuzzy to me now. Thanks for explaining it.
Please use a search engine to learn about "LBA"! It does not matter in your case.
Thanks. The Wikipedia page on 'Logical block addressing' helped refresh my memory a bit.
Reading through 'Step by Step' it looks like I see the same thing there, and am guessing it might just be a different way of confirming the '5 L HPFS - NTFS' partition below. That partition is labeled L for Logical, but it seems it ought to be Primary non-bootable.
For what reason should it be "primary non-bootable"? At least the legacy windows version assigned drive labels to primary partitions first and logical partitions later. When dealing with a data drive I guess one would rather prefer that label not messing around with the usual order of partition labels.
My mistake. I should have just said it ought to be labeled Primary.
Either your disk was already partitioned or you partitioned it yourself. By the way, it is better to say disk instead of drive because a drive is often associated with a partition, for instance, the C-drive, the D-drive etc. A disk refers to the whole physical entity regardless of the partitions inside.
'Disk' > Whole drive. 'Drive' > Partitions. Got it!
It seems when I lost all access to the file system for that drive back in the 00s, I chose 'L: load backup' to rewrite the partition table from a backup.
If you did not create a backup yourself, there is no backup, but there is no reason to change this partition table anyway.
I thought maybe 'L load backup' might have been referring to what I did back in the 00s when I used TeskDisk to restore, I think an MBR (or partition table?) from a backup copy that it seems is written to the very end of the disk or partition. I've yet to find that process that must be detailed somewhere in cgsecurity's documentation. Back then the gurus over in the Compuserve Windows support forums all told me the disk was a lost cause. Boy were they surprised!
So are you saying it wouldn't matter at this point if the data on the disk was originally on a Primary or Logical partition? And that you don't see an option here to get the disk recognized in Windows again?
Your are suspecting the problem in the wrong area.
You could copy the content of your disappeared partition to another disk using Testdisk using the "p"-key ("list files").
A smarter way would be to
1. Post your SMART parameters as described here
viewtopic.php?f=5&t=10910
That was pretty easy to figure out. I'll attach 2 versions. One using the -a switch as described there, and one using the -x switch as what was suggested at the end of the report generated with the -a switch. It all looks like Greek to me. Do they tell you anything that'd help here?
2. Depending on the result, cloning the disk using ddrescue as described in the manual.
Figuring how to install and run ddrescue got pretty convoluted. I have a copy of the Windows command line dd-0.5 from 2009 I used to clone a USB drive ages ago. I can't find any freely available copies of ddrescue that will run in a Windows GUI or command line. And for Linux there's seems to be 2 versions: 'GNU ddrescue' or just 'gddrescue', and 'ddrescue' that have been developed independently of each other. I've read some say ddrescue by Kurt Garloff might be more aggressive at imaging corrupted sectors.
I have 2 copies of Linux on bootable USB sticks. An 8 year old copy of Mint I love. The only other version I could get to boot and operate quickly recently is a flavor of Puppy Linux. The latter includes PuDD (Puppy Universal DD). And I was able to use Puppy's package installer to download and install gddrescue command line files.
99% of the files on this disk are just backups for ones on my W7 PC. But there are 1 or 2 I wrote to the disk I never backed up anywhere. I was able to copy them to another disk with TestDisk, but those copies fail to be read properly and open. I was hoping TeskDisk would have a "one click" option to get the disk recognized again in Windows, and that running chkdsk on it again might repair the damaged files. I did that successfully with another disk a while back.
3. Running TestDisk against the clone and extracting your data to another disk.
That would involve 3 disks?
Cloning a full disk is stressing the disk less than copying its content file-wise except for a pretty empty disk. On the other hand, TestDisk is not equipped with code to deal with broken sectors, but ddrescue is.
So I'm working on ddrescue. I haven't had luck cloning disks in Linux. My attempt cloning a Linux Mint USB stick with Clonezilla was a disaster. From what I wrote above, maybe you can clear a few things up and make some suggestions on the best path(s) forward.
Repairing the file system of a broken disk is rather the exception than the rule.
That's why I amazed myself and the CServe gurus when Christophe told me how to restore the MBR (partition table?) on that failed disk so many, many years back!