How to restore a corrupted hard disk image?

[ebann]

While using Basilisk, sometimes I have an unexpected crash or shutdown causing a subsequent boot to give me a "no disk" at startup.
I am presuming that the hard disk image is corrupted in some way. How do I "restore" my broken disk image?
Thanks!

[adespoton]

While using Basilisk, sometimes I have an unexpected crash or shutdown causing a subsequent boot to give me a "no disk" at startup.
I am presuming that the hard disk image is corrupted in some way. How do I "restore" my broken disk image?
Thanks!

The best way is to ensure you have backups prior to running your session so you can restore the backup.

The other is to keep an emergency image you can boot from, and then you can run Disk First Aid on the other image once you're booted.

[Ronald P. Regensburg]

The very best way is to make regular backups (or copies) of the hard disk image file. If the disk gets corrupted, simply replace the file with the latest backup (or copy). Don't you backup all your files regularly?

Edit: My reply and adespoton's crossed

[ebann]

The best way is to ensure you have backups prior to running your session so you can restore the backup.

The other is to keep an emergency image you can boot from, and then you can run Disk First Aid on the other image once you're booted.

While I do regular backups, I don’t do it prior every usage. I’m just used to my Windows and Linux systems “auto correcting” any improperly shutdown drive.

BUT if Disk First Aid will fully restore the “broken” disk then this is how I would prefer even though it’s a bit cumbersome.

Will try this! Thanks!

[emendelson]

You can always try booting to a minimal system with a copy of Disk FirstAid and try to repair the broken disk from there. It never worked for me, but it's worth trying.

[ebann]

You can always try booting to a minimal system with a copy of Disk FirstAid and try to repair the broken disk from there. It never worked for me, but it's worth trying.

Was it common to wreck your system partition upon a crash or improper shutdown on real Macs? Or perhaps Basilisk is prone to this, but real Macs aren't.

[emendelson]

You can always try booting to a minimal system with a copy of Disk FirstAid and try to repair the broken disk from there. It never worked for me, but it's worth trying.

Was it common to wreck your system partition upon a crash or improper shutdown on real Macs? Or perhaps Basilisk is prone to this, but real Macs aren't.

Only in Basilisk; never on a real Mac.

[Ronald P. Regensburg]

Well, I remember needing to check the integrity of the file system almost daily after a system crash in the System 7.5.x days.

In BasiliskII it will depend on what you are doing, which software you use. Disable extensions that are not needed, shut down the emulator when it is not actively used, and make sure you always shut it down from within the emulator, using Shut Down from the Special menu.

[emendelson]

Well, I remember needing to check the integrity of the file system almost daily after a system crash in the System 7.5.x days.

In BasiliskII it will depend on what you are doing, which software you use. Disable extensions that are not needed, shut down the emulator when it is not actively used, and make sure you always shut it down from within the emulator, using Shut Down from the Special menu.

Sorry: I wasn't being clear. I meant that I don't remember a disk becoming unusable after a crash on a real Mac. Like you, I had to run a disk check every time after a crash, but the Mac always at least rebooted. In Basilisk II - many years ago, anyway - I would sometimes have to replace the disk image with a backup.

[ebann]

Well, I remember needing to check the integrity of the file system almost daily after a system crash in the System 7.5.x days.

In BasiliskII it will depend on what you are doing, which software you use. Disable extensions that are not needed, shut down the emulator when it is not actively used, and make sure you always shut it down from within the emulator, using Shut Down from the Special menu.

Sorry: I wasn't being clear. I meant that I don't remember a disk becoming unusable after a crash on a real Mac. Like you, I had to run a disk check every time after a crash, but the Mac always at least rebooted. In Basilisk II - many years ago, anyway - I would sometimes have to replace the disk image with a backup.

Any ideas where the problem might lie? Why would Mac OS 7 be writing to some critical system boot files? Or disk structure elements? Maybe I should try a simple controlled crash and check the byte(s) differences that rendered the image bootless.

[emendelson]

Well, I remember needing to check the integrity of the file system almost daily after a system crash in the System 7.5.x days.

In BasiliskII it will depend on what you are doing, which software you use. Disable extensions that are not needed, shut down the emulator when it is not actively used, and make sure you always shut it down from within the emulator, using Shut Down from the Special menu.

Sorry: I wasn't being clear. I meant that I don't remember a disk becoming unusable after a crash on a real Mac. Like you, I had to run a disk check every time after a crash, but the Mac always at least rebooted. In Basilisk II - many years ago, anyway - I would sometimes have to replace the disk image with a backup.

Any ideas where the problem might lie? Why would Mac OS 7 be writing to some critical system boot files? Or disk structure elements? Maybe I should try a simple controlled crash and check the byte(s) differences that rendered the image bootless.

No idea, I'm afraid. Whatever you find out would be good to know.

[Ronald P. Regensburg]

Any ideas where the problem might lie? Why would Mac OS 7 be writing to some critical system boot files? Or disk structure elements?

The HFS file system cannot be compared to modern advanced file systems. Any fault or disturbance during writing to the disk can cause file system corruption. There is no automatic repair or correction built in and an initially minimal corruption on the disc can easily become worse in time with subsequent writing. There is also no specific protection for system files, all files on the disk are treated equally. In those days, you needed to regularly check and repair the file system on writeable HFS disks in order to keep them in good condition.

[mcayland]

You can always try booting to a minimal system with a copy of Disk FirstAid and try to repair the broken disk from there. It never worked for me, but it's worth trying.

Was it common to wreck your system partition upon a crash or improper shutdown on real Macs? Or perhaps Basilisk is prone to this, but real Macs aren't.

Only in Basilisk; never on a real Mac.

+1. I did some work for a client a couple of years ago using BII built from source (cebix repo) on Linux, and every time I accidentally quit BII by closing the window instead of shutting down from the Finder, it rendered the underlying disk image corrupted and unusable.

If I accidentally close the GUI window instead of doing a shutdown on QEMU, then everything is fine (with the occasional warning about the computer not being shutdown cleanly) so BII definitely does something odd here.

[adespoton]

The reason for the difference between BII and real hardware I suspect comes down to how BII handles disk images -- meaning, none of the actual hardware is emulated, and not even the actual disk structure is maintained -- BII works against the HFS partition directly.

This means that all the SCSI integrity checks, caching, and driver protections are totally missing in BII, so if the emulator is interrupted when writing something important, that's it for the partition integrity; there's no backstop.

With Mac OS 9, you get DFA being auto-run at startup, so SheepShaver doesn't tend to run into these issues, but with BII, you have to do it yourself -- and HFS is less tolerant of interrupted writes than HFS+ in the first place.

[mcayland]

The reason for the difference between BII and real hardware I suspect comes down to how BII handles disk images -- meaning, none of the actual hardware is emulated, and not even the actual disk structure is maintained -- BII works against the HFS partition directly.

This means that all the SCSI integrity checks, caching, and driver protections are totally missing in BII, so if the emulator is interrupted when writing something important, that's it for the partition integrity; there's no backstop.

With Mac OS 9, you get DFA being auto-run at startup, so SheepShaver doesn't tend to run into these issues, but with BII, you have to do it yourself -- and HFS is less tolerant of interrupted writes than HFS+ in the first place.

I don't believe that's the case here though. As an example when booting a MacOS 8 image under QEMU I can see from the SCSI logging that disk activity quiesces within a couple of seconds of reaching the Finder. Although BII intercepts the SCSI disk routines and redirects them to the host, the pattern of writes issued by the Toolbox ROM will not change and so we know that BII must also quiesce within a similar timeframe. Now if I close the BII window, I know that there is no write activity and still the disk image is corrupted.

If I had to make a guess I would say that there is no SDL window shutdown handler that flushes and closes the underlying disk images on BII, however I don't have enough knowledge of the BII codebase to confirm this. Based upon my experience with QEMU though, what I can say with confidence is that this is specifically a BII issue.

[adespoton]

The reason for the difference between BII and real hardware I suspect comes down to how BII handles disk images -- meaning, none of the actual hardware is emulated, and not even the actual disk structure is maintained -- BII works against the HFS partition directly.

This means that all the SCSI integrity checks, caching, and driver protections are totally missing in BII, so if the emulator is interrupted when writing something important, that's it for the partition integrity; there's no backstop.

With Mac OS 9, you get DFA being auto-run at startup, so SheepShaver doesn't tend to run into these issues, but with BII, you have to do it yourself -- and HFS is less tolerant of interrupted writes than HFS+ in the first place.

I don't believe that's the case here though. As an example when booting a MacOS 8 image under QEMU I can see from the SCSI logging that disk activity quiesces within a couple of seconds of reaching the Finder. Although BII intercepts the SCSI disk routines and redirects them to the host, the pattern of writes issued by the Toolbox ROM will not change and so we know that BII must also quiesce within a similar timeframe. Now if I close the BII window, I know that there is no write activity and still the disk image is corrupted.

If I had to make a guess I would say that there is no SDL window shutdown handler that flushes and closes the underlying disk images on BII, however I don't have enough knowledge of the BII codebase to confirm this. Based upon my experience with QEMU though, what I can say with confidence is that this is specifically a BII issue.

Well, specifically a BII and SheepShaver issue. And I suspect you're correct about flushing and closing the underlying disk image. This should be fixable, but it's been years since I've fiddled around in that area of BII. It should be possible to automatically flush to disk from the SDL window shutdown handler as well as via the existing in-app shutdown routine.

Maybe someone like KanjiTalk755 who's looked more recently would have an idea?

[ebann]

I also managed to render a disk unbootable with Mini vMac in “Macintosh II” emulation. I had my Mac OS 7.5.5 hang running a misbehaved compiled binary (CodeWarrior 11). I closed the window and restarted but it wouldn’t boot anymore. I will try again to be sure.

[adespoton]

I also managed to render a disk unbootable with Mini vMac in “Macintosh II” emulation. I had my Mac OS 7.5.5 hang running a misbehaved compiled binary (CodeWarrior 11). I closed the window and restarted but it wouldn’t boot anymore. I will try again to be sure.

Sounds like it emulated a Macintosh II perfectly then