hey, you're completely right - I was just too irked and should have waited to send it. I am back to being a nice person again, now that I'm mostly over losing so much stuff.
That said, I see that this very same bug is mentioned repeatedly online... considering that eating hard drives is just about the worst thing a program can do I must say this is a very bad situation. Well, it could have actually sanitized it by writing random stuff through the whole thing, but that is the only thing worse I can think of. Since this is a known issue there should be some sort of indication put in until a patch is in place. I don't have the expertise to fix it myself or I gladly would. Would you please please please mark this as a high priority bug, if that is possible? Though I now see I should have been more careful at the time I thought I was being perfectly safe since it was, in theory, not even touching the partitions with data on them! Instead I find I lost everything I'd had on that drive... luckily the pictures of my dead family are backed up (but can you see why I was so upset? Not that being mean in return was called for, I admit) but everything else wasn't. Keep in mind that the vast majority of people do not back up anything at all. I have since totally changed that hard drive so I can't provide the files you mentioned, would have done so but didn't know what to include. Here's what I can tell you, please pass this on to the right folk if you can, or let me know if/where I should post or send them: The problem seems to lie with qtparted, at least in part. To start with I had played around with my partitions quite a lot before switching to kubuntu. Using GParted, I created, deleted, moved, etc. partitions a whole bunch. I did something like the following: Create partitions: hda1 (primary) hda2 (swap) hda5 (extended) hda6 (logical) hda7 (logical) Deleted hda6 added hda8 and hda9 so it ended up in this order on disk: hda1 hda2 hda5 hda8 hda9 hda7 See? qtparted didn't get this... nor did it simply apply a different name to each one! Instead it somehow did a mix of the two: it would show the right information for each partition (in terms of fs type, size etc.) but when you went to actually CHANGE a partition (by formatting or deleting!!) it would instead change the wrong one! After it finished you'd see a different one changed than the one you selected. I was sure I was at fault, that I'd simply chosen the wrong one, but tested and found that that was not the case. Here are some screen shots to show you... qtparted and gparted showing same HDD & partitions very differently: http://i18.tinypic.com/40127pt.jpg fdisk -l output: note "Partition table entries are not in disk order" http://i18.tinypic.com/43cyds8.jpg Sorry for the camera screen shots but I didn't know at the time if I could expect to later be able to find anything I saved to disk since it was wiping partitions. I'm not entirely sure that my partial understanding of what went wrong is even correct, as incomplete as it is, but I know there is something wrong! I don't know if gparted was at fault as well - was it not supposed to number them that way? Seems like it should, since you'd not want to have to go in and chance references to existing partitions if they were renumbered instead, or so I'd think. Either way, qtparted definitely bugged out by changing different partitions than it is told to. Thanks for your measured response to my aggravated and cranky bug report. Hope this helps. Thanks -- manual partitioning fails in numerous fatal ways https://launchpad.net/bugs/84473 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
