[comp.sys.apple] Questions about GS System Disk 5.0

DCS100@PSUVM.BITNET (David C. Schweisguth) (08/22/89)

     Here are a bunch of questions about GS System Disk 5.0 for all you
knowledgeable folks out there. I hope the collective readership has enough
collective time to answer them; I'll be perfectly happy with short answers.
Please mail your responses; I will summarize and post.

     1) What are the purposes of the following files:
          System/GSOS.Dev?
          System/System.Setup/Resource.Mgr?
          System/System.Setup/Sys.Resources?
          System/Fonts/Fast.Fonts?

     2) How does Expressload do its thing? Does it depend on the physical
placement of disk blocks, and if so will it be mucked up by copying
Expressloadable files with utilities other than the newest Installer or Finder?

     3) Virus Detector V1.2 always detects a virus on copies of my presumably
virgin System Disk 5.0. It continues to do so after it has supposedly fixed the
boot block. This happens when VD is the first or last file in System/
System.Setup; I haven't tried other placements. I guessed that a) the boot
block has been changed (as with GS/OS V2.0) and b) VD can't write over it for
some reason, but that's only a guess. Any ideas? (No, the disks on which I've
tried this have not been write-protected.)

     4) Is the file System/Start.GS.OS supposed to be unlocked (if locked) or
written to during normal GS/OS operation? I normally keep all my non-document
files locked, and Start.GS.OS won't stay that way. The modification date is
still June 14th. This happened with System Disk 4.0 as well, but I never got
around to asking anyone about it.

     5) I attempted to copy the entire system file-by-file from one 3.5" disk
to another using Copy II Plus. Only one block each of Sys.Resources,
Ctlpanel.NDA, Cdev.Data, and each of the CDevs made it to the target volume.
Copy II Plus did not report any errors. The Finder from System Disk 5.0 copied
the same files correctly. Are these (gulp) forked files?

     6) There seems to be a bug in the standard file opening dialog. I have two
3.5" drives, so when I want to load an existing document into an application I
normally boot the system from drive 1, launch the application from drive 2, put
the disk with the document in drive 2, and then open the document. Under GS/OS
V3.0 this sometimes hangs the system, as if it were still expecting the
application disk in drive 2. This only happens when I do this immediately after
launching the application (any application); after one successful dialog
everything works fine. I can work around it by selecting Load, Open, or
whatever with the application disk still in drive 2 and then tabbing to the new
disk, but I shouldn't have to. Has this happened to anyone else? Any ideas?

     7) What would happen if I deleted Ctrlpanel.NDA, CDev.Init, and the CDevs
directory? I haven't tried yet, but I might want a really stripped-down system
some day, and they take up a lot of space for something I don't use much.
 _____________________________________________________________________________
/                                                                             \
| David C. Schweisguth     406 Althouse Laboratory   "When one has much to    |
| AppleLink PE: Von Mordo  University Park, PA 16802  put into them, a day    |
| Bitnet: DCS100@PSUVM     814-862-0806 (home) or     has a thousand pockets."|
| GEnie: D.SCHWEISGUT      814-863-2791 (work)        -- Friedrich Nietzsche  |
\_____________________________________________________________________________/

fadden@cory.Berkeley.EDU (Andy McFadden) (08/22/89)

In article <89233.162153DCS100@PSUVM> DCS100@PSUVM.BITNET (David C. Schweisguth) writes:
>     5) I attempted to copy the entire system file-by-file from one 3.5" disk
>to another using Copy II Plus. Only one block each of Sys.Resources,
>Ctlpanel.NDA, Cdev.Data, and each of the CDevs made it to the target volume.
>Copy II Plus did not report any errors. The Finder from System Disk 5.0 copied
>the same files correctly. Are these (gulp) forked files?

Yes.

>     6) There seems to be a bug in the standard file opening dialog. I have two
>3.5" drives, so when I want to load an existing document into an application I

This is nothing new.  Strange things used to happen to me in SHRConvert (all I
had was one 3.5" drive) unless I made sure that things happened in the right
order.  It wasn't really repeatable (I wasn't sure if I should blame my drive,
the SFTools, or what, and it only happened in SHRConvert...), so I never sent
it in to Apple.

>| David C. Schweisguth     406 Althouse Laboratory   "When one has much to    |

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden