I deleted the RDSK ID in the first block of my bootable USB ZIP drive (just
like the Elbox code would have done). On the next startup, it didn't boot
from it and no partitions were found.
I loaded up HDToolBox (OS3.1), it said "Unknown" at the ZIP drive line.
I called up "Change Drive Type", clicked on "Define New", "Read Configuration", then on "Ok"
I pressed "Save Changes to Drive". I did NOT call up "Partition Drive".
>After this, the old partition data (PART block) had been erased. Gone.
>Finito. There was the default "IDH0" partition, but my former SFS partition
>was gone. If I had more partitions on my ZIP, they would be gone aswell. In
>case I could /remember/ the *exact* values for each partition, I might be
>able to reconstruct the partitions without loss of data. But who has these
>numbers written down somewhere?
I went through this not too long ago. I got an 18gig drive, using OS3.9. When I got a CD burner, I decided to make an 800MB partition at the top of the 18gig, as the previous top partition wasn't rally used, and I did want it smaller to only fit the amount of data a CDROM can take, in order to assemble iso files for burning backups and such.
Well, at that time, OS3.9 format command had a bug that couldn't deal with partitions above the 4gig line when doing a full format, though quick formats would be fine. I didn't know this bug, and of course ended up doing a full format on this top partition. Since OS3.9 format had the bug, it didn't format the top 800MB, it wrapped around and trashed the bottom 4gig area including my system partition and Mac emulator partitions, and also wiped out the RDBs.
So, my system was now completely unusable.
Teh data above that 4gig mark was still there, and still intact, but was in a state of limbo. I tried disksalv, but without RDBs, there was no partition to salv. I got the OS3.9 beta of another salvage tool, but it also was unable to do anything without RDBs. I tried guessing partition sizes and locations, and using a disk editor, and managed to get close, but still had some problems.
While the disk editor allowed me to get close, I wasn't able to recover anything usefully. Turned out, this drive had been partitioned using OS3.1 HDtoolbox, which used a 512 default block size, and OS3.9 HDtoolbox used a 1024 block size, and I was trying to salvage and guess new partitions using OS3.9 recover disk with OS3.9 HDtoolbox, which kept making half my partitions one half block size off, the closest I could get until someone helped me understand this and OS3.1 HDToolbox worked fine.
I have since registered a copy of RDBsalv and this OS3.9 disk recovery tool (sorry, forget its name) so I will be prepared if this ever happens again.
But, this first time, it took **3 MONTHS** to recover my data. My main computer was UNUSABLE for this entire 3 months. My data was inaccessible. My software was unusable. I had to USE WINDOWS for cryin out loud, it was that bad.
So, with someone testing and finding that Elbox's supposed method of recovery indeed does not bring the old partitions back to life, I fear going through my experience above again. 5 minutes my ass.
If the RDB partition table is indeed overwritten by HDtoolbox in Elbox's recovery situation (as it thinks it's defining a new drive for the first time), and you don't have those RDBs backed up somewhere, YOU ARE REALLY REALLY SCREWED. I found out the hard way with OS3.9's format bug.
I won't be finding out if some other softwar ebug triggers a hidden Elbox piracy protection scheme, be it this RDSK or whatever they changed it to that might be just as bad or worse. The only Elbox thing I have is an IDE buffer for my 1200, for the sole purpose of using their AllegroCDFS software (it's the hardware dongle, I don't actually use the hardware for IDE stuff) but I ended up using AsimCDFS anyway. I won't be using any other of their products now. Piracy protection is not a good reason to put destructive code in an unprotected environment, as there's no *guarantee* it won't go off outside of Elbox's intentions. It's impossible to *guarantee* it *can not* go off outside of Elbox's intentions. Therefore it is a bad idea. Find a non-destructive way of doing things, that's OK.
