Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!apple!mattd From: mattd@Apple.COM (Matt Deatherage) Newsgroups: comp.sys.apple Subject: Re: file system questions Message-ID: <38762@apple.Apple.COM> Date: 19 Feb 90 19:13:20 GMT References: <1557@crash.cts.com> <38736@apple.Apple.COM> <3637@sage.cc.purdue.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 105 In article <3637@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes: > > GS/OS on the other hand is a complete rewrite and thus CAPIBLE of >larger volume sizes. Take a closer look at GS/OS and see that it uses >FSTs to do all the low level work with the hardware. In knowing this, >it's easy to see that volume size for GS/OS is limited by its FSTs. So >what FSTs are there? > Dave has already addressed some of this, but to repeat, drivers talk to the hardware, FSTs talk to the drivers, GS/OS talks to the FSTs, applications talk to GS/OS. The volume size for "GS/OS" is limited by the data structures used by GS/OS's abstract file system. GS/OS uses a four-byte field for number of blocks on a volume, and a two-byte field to indicate how many bytes per block. Theoretically, that gives $FFFF * $FFFFFFFF bytes per volume, or a limit of 2.8E14 bytes per volume. Most file systems (the method used to organize bytes on a disk into files and directories) have smaller limitations than this. > There is a ProDOS FST, this is what must of us are use to, because >it is so simular to ProDOS 8, but has a few extentions, like forks. > Again, an application makes GS/OS calls, not "ProDOS FST calls" (with some very minor FST-specific exceptions). The ProDOS FST allows GS/OS to use ProDOS disks. The FST has all the limitations of the native (in this case, ProDOS) file system, including that on ProDOS disks, you have two bytes that indicate how many 512-byte blocks are on the disk, for a total of 32 MB. Changing this means that any ProDOS 8 software that works with these disk structures directly will not work with these disks (not just with some files on the disk, but with the disk itself). That makes it not exactly a ProDOS disk. ProDOS's file system has fortunately always supported storage types, so other programs or operating systems (Pascal, GS/OS) can create files on ProDOS disks that ProDOS 8 won't try to mess with. That's how Pascal Volumes and Extended Files can fit on those disks without ProDOS 8's knowledge. Changing the whole disk so ProDOS 8 can't use it is an entirely different matter. > There's a Sierra-Online FST. This allows those who have expensive >CD drives to READ CDs. If and when CDs become writeable, this FST will >not allow you to take advantage of that since the FST is READ ONLY. > There's a "High Sierra" FST; Sierra On-line has nothing to do with this international standard for CD-ROM disks which was created at a conference at the High Sierra resort in Nevada. The FST doesn't support writing because CD-ROM is currently not a writeable technology. If this changes, the FST can change. That's why it's not in ROM. > Now there's an AppleTalk FST. This gives us read/write access on >AppleTalk networks. What percentage of GS users are hooked up to >networks? I would say not many. And who is going to run out and buy >a Mac, hard drive and the networking software just so they can have a >large storage device to run there GS files from? I suspect none. > You would be incorrect. Schools were crying for AppleShare access under GS/OS ever since GS/OS was released. We listened, we created. As Dave says, AppleShare (it's not an "AppleTalk FST"; AppleTalk is not a file system) is a complete networking solution, not a method for individual people to use larger hard drives (although it does work for that as well). > There is also a Character FST. I don't know about you, but I don't >see any acceptible way of storing/retrieving files from there. > The Character FST is essential to the I/O model of GS/OS. It's not SUPPOSED to be a way to access a file system; it deals with the character side of the I/O model (other FSTs deal with the block side). > So Matt, you say ProDOS 16 and GS/OS were written to get around the >limitations of ProDOS 8? The only storage capicaty limit that I see as >being removed is the number of volumes per slot. With the size of hard >drives getting larger, we still CANNOT make good use of them without >having to resort to defining many partions to fill the space. This is >another main reason why we want a mac FST, so we can format the hard >drive to one big volume! Some will even settle for a FST of a new file >system, one that will permit GS/OS to live up to its fullest protentials! > >-- > ____ > Y_,_|[]| Eric Mulholland >{|_|_|__| aj0@sage.cc.purdue.edu >//oo--OO ...!pur-ee!sage.cc!aj0 ProDOS 8 can't read data into banks other than zero. GS/OS can. PrODOS 8 can't deal with multiple file systems. GS/OS can. ProDOS 8 forces you to interpret directories yourself. GS/OS doesn't. ProDOS 8 has 15-character file name limitations. GS/OS doesn't. ProDOS 8 has one prefix. GS/OS has 34 (counting *: and @:). ProDOS 8 has a 128-character pathname limit. GS/OS's is 8,000 characters. ProDOS 8 can only have two devices per slot. GS/OS is not limited here. ProDOS 8 has file system limitations. GS/OS's are much larger. Etc., etc., etc. What you want is a newer FST (like HFS) to address the file system problems associated with ProDOS. No one is arguing against that. What I was saying is that ProDOS 8 (the 8-bit disk operating system) isn't going to deal with volumes greater than 32 MB. That stands. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================