Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!labrea!Shasta!gus
From: gus@Shasta.UUCP
Newsgroups: comp.sys.mac
Subject: Re: Possible bug in AppleShare, System 3.3/Finder 5.4
Message-ID: <1310@Shasta.STANFORD.EDU>
Date: Sat, 21-Feb-87 13:55:59 EST
Article-I.D.: Shasta.1310
Posted: Sat Feb 21 13:55:59 1987
Date-Received: Mon, 23-Feb-87 05:43:36 EST
References: <809@crash.CTS.COM>
Organization: Stanford University
Lines: 22
Summary: Response to boot block problem

In article <809@crash.CTS.COM>, dbw@pnet01.CTS.COM (David B Whiteman) writes:
> I was at an Apple Dealer today, and the following problem occurred several
> times while I was there.  I was wondering whether anyone else observed this
> problem.  Basically a Mac running AppleShare was being used to create new
> system startup discs with various fonts
...
> The resulting disc would not be able to boot a Mac; further analysis using
> Fedit + showed that the boot blocks were never written.  I thought that the
> boot blocks were always written when the finder moves the system to a disc.

The Finder copies boot blocks to a disk from the source disk when you copy a 
System and Finder to it (and there was not one there already.) Since AppleShare
is an External File system, (the protocol does not demand that the Server be
a Mac - only the current implementation...) there really is no place that the
Finder can get the original source boot blocks from. Although the local
system must have boot blocks, (ou  cannot boot off of AppleShare) boot block
parameters such as Finder and Startup file names, and system heap size can
vary from disk to disk, so this is not reliable.

The only current solution is to first copy a local system and finder to the
floppy, and then to overwrite what you need from the server. Fedit's "Write
boot blocks" function also seems to work pretty well.