Hi Joel, thanks for taking a few minutes to read and reply to my plea. > Try GPT partitions.
My priority is to recover several weeks' worth of personal data that is almost certainly still present on the array, not to get the array working again. The important unanswered question is, "How could this happen"? The only two explanations I can conceive for encountering the problem in the first place are: 1) Since gpt and msdos partition tables can coexist on a device due to different physical locations (modern macs do it all the time), some applications may be confused/misled about which partition table to read/use, OR 2) A GPT partition was never created in the first place, in which case parted not only happily let me create an illegally large msdos partition, but also proceed to use it for a month with absolutely no problems whatsoever -- that is, until the machine was rebooted (see the link in my reply to Håkon; someone else has reported precisely this problem in this list earlier this year). I know for certain that I originally partitioned the drive using fdisk, which would ensure that an msdos label is present on the drive regardless of any other partition tables present; my reaction to the limited disk size was how I came across parted at all. Back to your suggestion: if I run `parted /dev/sdb mklabel gpt` and I'm dealing with case #2 above, it seems a lot less likely that the data will ever be recoverable. Conversely, if the first case applies then restoring normal access to the drive should involve little more than "zapping" the msdos label so that whatever software is detecting it now will ignore it and find the gpt label instead. My point is, before doing anything destructive to the data on the drive, I want to determine which of the two points above is the case. I have a strong suspicion that it is #1, but I don't have the technical knowledge to be able to tell whether or not this is the case with any level of certainty. At present, I have two goals: 1) With someone's generous help, conclude whether the problem is one case or the other with some degree of certainty, and select an appropriate strategy to attempt to recover the drive's data; and 2) Assist in resolving whatever defect is responsible for encountering this issue in the first place to prevent similar misfortune/frustration from befalling others. Cheers, Kevin Williams _______________________________________________ bug-parted mailing list bug-parted@gnu.org http://lists.gnu.org/mailman/listinfo/bug-parted
