dbw@crash.UUCP (02/18/87)
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 varoius fonts. The Mac was booted initially with system 3.3/Finder 5.4 and placed on AppleShare. A blank disc was then formatted and a System 3.2 was dragged from a shared folder on the AppleShare volume to the blank disc. Some laserfonts were added to the system using Font/DA mover 3.2, and then Finder 5.3 was dragged over from the same folder to the same disc. During this process only the Finder was used to move files. 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. All the Macs on the AppleLink network were running 3.3/5.4, both were MacPlus's, the AppleShare volume was on an HD20SC.
scott@apple.UUCP (02/19/87)
In article <809@crash.CTS.COM> dbw@pnet01.CTS.COM (David B Whiteman) writes: >... Basically a Mac running AppleShare was being used to create new >system startup discs with varoius fonts. ... >... A blank disc was then >formatted and a System 3.2 was dragged from a shared folder on the AppleShare >volume to the blank disc. ... >The resulting disc would not be able to boot a Mac; further analysis using >Fedit + showed that the boot blocks were never written. The boot blocks of an AppleShare server cannot be read (they are outside of the volume). Finder 5.4 knows this and doesn't try to copy them which causes the problem you describe. A work-around is to copy on a System file from a non-AppleShare volume first. -- --scott douglass, Apple Computer CSNet: scott@Apple.CSNet UUCP: {nsc, voder, well, dual}!apple!scott AppleLink: Douglass1 Any opinions above are mine and not necessarily those of Apple Computer.
gus@Shasta.UUCP (02/21/87)
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.