• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Mac Plus and System 7.0.1: Address Error when Rebuilding Desktop

Iesca

Well-known member
Hello all,

I decided to try upgrading the system on my Mac Plus's external hard drive from 6.0.8 to 7.0.1. I used the Net Install of 7.0.1 and installed it to the drive over AppleShare from another Mac. It modified my original System unfortunately (I had renamed the System Folder in an attempt to avoid this), but regardless, when it finished, I restarted, and following the boot sequence the system began rebuilding the desktop for my external SCSI drive.

As the process approached its end, the dreaded bomb appeared: Address Error. Restarting with Extensions Disabled results in the same thing. However, I can cancel rebuilding the desktop, and everything hums along normally.

The Mac Plus has been upgraded to 4MB of RAM, and the external drive is a Seagate ST157N (identified by La Cie's Silverlining 5.31 as a Cirrus 45, though it resides in a GCC UltraDrive 40S enclosure). Silverlining has already mapped out the bad sectors on the drive, and I have run various memory tests using Snooper and MacTest.

I have not yet scoped out which version of the ROM is installed on the logic board, though I know that the main differences are with regards to external SCSI devices.

Should I just start over and try a clean install of 7.0.1? Or is this something I can remedy more simply? Again, disabling extensions does not affect anything.
 

Iesca

Well-known member
Tried re-installing 7.0.1 fresh with no prior System Folder, same Address Error about 80% of the way through rebuilding the desktop. Deleted old System 7 Desktop Files for good measure, and still no dice.

Very frustrating.
 

Crutch

Well-known member
I have not experienced this before. Here are a collection of ideas:

  1. This is probably a software error, but you’ve tried the most obvious things absent Macsbug. Here are some other ideas:
    1. Start deleting applications from your hard drive one by one and see if it stops happening — the fact that it always happens at a certain point in the rebuild makes me think Finder is stumbling on a badly corrupt file some how that is confusing it
    2. Install Macsbug and post a screenshot of what it shows on the crash and I or someone can try to diagnose (assuming you aren’t a Macsbug expert)
    3. Re-initialize your hard drive and start from scratch
  2. Just in case it’s a hardware issue:
    1. Try a different hard drive
    2. Try this on a different Mac, if you have one
    3. Try swapping out your RAM?
 

Iesca

Well-known member
Turns out it was indeed choking on a particular piece of software. Once I narrowed it down and tossed it, it was able to rebuild, no problem. Thank you for your insight, @Crutch!
 

Iesca

Well-known member
I just deleted it, but I can tell you what it was: a folder copy of the MacTest Pro Emergency Disk.
 

MrFahrenheit

Well-known member
Norton Utilities is invaluable in fixing these sorts of issues. For System 7.0.1 I'd recommend something in the 2.0 but to be safe maybe have 3.2.4, as it's good upto System 7.6.1.
 

cheesestraws

Well-known member
I just deleted it, but I can tell you what it was: a folder copy of the MacTest Pro Emergency Disk.

Would be interesting to know whether you can reproduce it by making another folder copy of that disk, if you have time. (This is pure curiosity on my part; I've been reading too much about the desktop manager recently, so please feel free to tell me where to stick it if you have better things to do)
 

MrFahrenheit

Well-known member
Would be interesting to know whether you can reproduce it by making another folder copy of that disk, if you have time. (This is pure curiosity on my part; I've been reading too much about the desktop manager recently, so please feel free to tell me where to stick it if you have better things to do)

I have had Norton Utilities warn me on some files that the resource fork is damaged on a file or program, and that it would affect desktop rebuilds. I wonder if this is a case where that would happen.
 

cheesestraws

Well-known member
Yup, but I'm a bit interested in precisely what that means, especially in this case. I'm throwing around ideas for a project that involves doing inadvisable things to the desktop database, and it'd be useful to have some pathological cases to know what not to do :)
 

MrFahrenheit

Well-known member
Yup, but I'm a bit interested in precisely what that means, especially in this case. I'm throwing around ideas for a project that involves doing inadvisable things to the desktop database, and it'd be useful to have some pathological cases to know what not to do :)

While Mac system is loading, pull plug. While App is loading, pull plug. Or force quit (interrupt G 40f6d8 ). While copying app from one device to another, force Finder to quit. Or pull plug. Write files to a hard drive with no terminator installed. Write files to hard drive with two SCSI devices sharing same SCSI ID. I could come up with numerous cases where corruption could possibly happen.
 

cheesestraws

Well-known member
I could come up with numerous cases where corruption could possibly happen.

The problem with this approach is that "corruption" isn't really one thing; in fact, it's more saying what the data is not than what it is. A file is corrupt when it does not contain what it was intended to contain, and has reached this state by unclear and chaotic means. That is all. This means that when one is trying to understand specific malfunctions, "corrupt" vs "not corrupt" is not a very useful category.

The resource fork, especially, is structured in multiple ways on multiple levels, and by no means all resource fork corruption will cause errors in desktop database rebuilds. The answer you just gave is like someone trying to diagnose a specific filesystem malfunction and being given the answer "No, but I can generate another corrupted filesystem for you" and filling it with random cruft. If, for example, the issue that person was trying to uncover was catalogue corruption due to erroneous copying of damaged data, the production of a corrupted file corrupted in a completely different way proves nothing. In this case, especially, we have a known fragile mechanism (the FREF resource, which is an overengineered mess), and I want to see, specifically, whether that is what has gone wrong here.

Fuzzing the desktop manager, which is essentially what you are suggesting by a very slow route, would doubtless turn up multiple crashing bugs. I don't want that list of crashing bugs caused by abuse; I want to know about something I suspect is a structural fragility.
 

Iesca

Well-known member
So, I reinstalled it to the drive, and tried rebuilding the desktop. It was able to complete without error, so this points to one of two things:

1.) Either, the file/files became corrupted at some point, or

2.) Something happened with a sector the file/files were written to on my drive. (This could also be a cause of the file/files becoming corrupted.)
 

MrFahrenheit

Well-known member
The problem with this approach is that "corruption" isn't really one thing; in fact, it's more saying what the data is not than what it is. A file is corrupt when it does not contain what it was intended to contain, and has reached this state by unclear and chaotic means. That is all. This means that when one is trying to understand specific malfunctions, "corrupt" vs "not corrupt" is not a very useful category.

The resource fork, especially, is structured in multiple ways on multiple levels, and by no means all resource fork corruption will cause errors in desktop database rebuilds. The answer you just gave is like someone trying to diagnose a specific filesystem malfunction and being given the answer "No, but I can generate another corrupted filesystem for you" and filling it with random cruft. If, for example, the issue that person was trying to uncover was catalogue corruption due to erroneous copying of damaged data, the production of a corrupted file corrupted in a completely different way proves nothing. In this case, especially, we have a known fragile mechanism (the FREF resource, which is an overengineered mess), and I want to see, specifically, whether that is what has gone wrong here.

Fuzzing the desktop manager, which is essentially what you are suggesting by a very slow route, would doubtless turn up multiple crashing bugs. I don't want that list of crashing bugs caused by abuse; I want to know about something I suspect is a structural fragility.

The response you just gave is over the top.

I was merely giving you suggestions on how to simulate corrupted files for your 'project'. Calm down.
 
Top