price@mandala.unl.edu (Chad Price) (08/22/90)
In <1990Aug21.094541@mobius.Viewlogic.COM> greg@mobius.Viewlogic.COM (Gregory Larkin) writes: >I have just purchased Minix 1.3 from PH. The system configuration is a >6 MHz IBM AT. One >1.2 MByte floppy, a 20 MByte hard disk (type 2 - C:) and a 30 Mbyte >hard disk (type 3 - D:). >I just installed the 30 meg disk last night, intending on installing >Minix on it and keeping >DOS on the 20 meg disk. >Well, I was playing around with Minix and created a 100 block empty >file system on /dev/hd0. >Apparently, this trashed the COMMAND.COM on C:, because I can no longer >boot DOS from the hard >disk (D: had been empty). Does anyone know if something like NORTON >utilities can get at my >files on the C: drive? I don't really care if I have to extract the >files to D: and then >reformat C:. Is there an easier way I can recover from this *stoopid* >(sic) mistake?? I'm not sure there is an easy way: you may have overwritten your parttion table and the FAT, as well as easily replaced items like files. My memory of Minix is that /dev/hd0 treats the ENTIRE disk as a Minix partition, regardless of the partition table. What I would try for this problem is to swap your C & D drives, do a sys on D (now C) (after reformatting it if necessary), and boot from it. THen use something like Norton Utilities or Mace to attempt to recover anything you can and want from your former Drive C. Before I tried the solution in the previous paragraph, I would boot from a floppy and see if I could make any headway using a data recovery program from the floppy. Norton & other recovery probems can read absolute sectors on apparently dead drives, but unless the file you are looking for is ascii or some semblance thereof, and the file is either small , or you have reorganized your drive so that files are in contiguous regions, finding the data may be quite a chore. This kind of problem is discussed in the book on data recovery by Paul Mace. BTW - I made the same mistake when I first played with Minix, and recovered by restoring from a backup. No other option seemed feasable in a reasonable amount of time. Chad Price price@fergvax.unl.edu