johnmac@fawlty.towers.oz (John MacLean) (10/04/89)
In article <4454@internal.Apple.COM> you write: >In article <404@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >>Why has Apple released a CD-ROM FST and an Appleshare FST but has >>not provided DOS 3.3, or MAC (MAC should be very simple given the >>back end of the Appleshare FST could be copied)? > > It's not that simple, because the Appleshare FST knows > nothing about the HFS disk structure used on Macintosh > volumes. > [lots more deleted ...] > >Cary Farrier I hate to go on about FSTs - the issue has been flogged to death. At least these discussions have raised awareness of what can (will?) be done - and thus will increase user demand and hopefully move some butts. Anyway the response: Its true that the Appleshare server need not be a Mac, but Appleshare was designed with the Mac as a server. Thus all the info passed to and from the Appleshare server (through the Appleshare commands), maps directly onto stuff relevent at the low level HFS structure. Thus the Appleshare FST does much of the high level translations that are necessary to map onto MFS or HFS. Sure it knows nothing about how all this stuff is physically arranged on each block of the disk, or even that a disk has blocks. An FST must map file names and file info between OS's as well as handling the low level stuff - so perhaps when I said the "back end" I caused confusion (maybe "front end" is more appropriate?). Anyway, even the low level stuff is not very complex as the smartport interface supports reads and writes of 524 byte blocks for the Mac directly, so all you need is the directory structure and file manipulation. I remember putting Mac HFS and MFS reads into The Graphic Exchange in ONE WEEKEND before Applefest at the end of last year; quite a few bugs were uncovered later, but it shows that things are not as complex as some will have us believe. All I want is some FSTs for the real people. Always the critic ... John MacLean. Action is one sure way to silence the critics. -- Internet: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 UUCP: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 Snail: Tower Technology 31-33 Sirius Rd, Lane Cove, NSW 2066, Australia. -- Internet: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 UUCP: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 Snail: Tower Technology 31-33 Sirius Rd, Lane Cove, NSW 2066, Australia.
dlyons@Apple.COM (David Lyons) (10/08/89)
In article <502@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >[...] so all you need is the directory structure and file manipulation. >I remember putting Mac HFS and MFS reads into The Graphic Exchange in >ONE WEEKEND before Applefest at the end of last year; quite a few bugs were >uncovered later, but it shows that things are not as complex as some >will have us believe. John, I agree with almost everything you said. I just have to point out that *writing* to an HFS volume is more complicated than reading it (since you have to rearrange the B-tree (or is it B*-tree?) directory structure whenever you add, delete, or rename a file). Bugs in *reading* a disk are a nuisance, but any bugs in *writing* could destroy people's volumes. -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
blochowi@rt5.cs.wisc.edu (Jason Blochowiak) (10/09/89)
In article <35363@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes: >In article <502@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >>[...] so all you need is the directory structure and file manipulation. >>I remember putting Mac HFS and MFS reads into The Graphic Exchange in >>ONE WEEKEND before Applefest at the end of last year; [...] >John, I agree with almost everything you said. I just have to point out >that *writing* to an HFS volume is more complicated than reading it (since >you have to rearrange the B-tree (or is it B*-tree?) directory structure >whenever you add, delete, or rename a file). Bugs in *reading* a disk >are a nuisance, but any bugs in *writing* could destroy people's volumes. This is true, however don't you think that most people would be happier if they had a read-only FST as opposed to having nothing at all? It would seem that they could port the HFS read and the common code that read uses first, throw that puppy out the door, and then work on putting in writes, renames, formats, etc. The worst that would happen with a buggy read-only HFS FST would be that someone would try to copy/import some file, and it would be trash (well, this is assuming it didn't do a DWrite somewhere...). Anyways, for all of Apple's comments about their inability to comment about Apple products that haven't been released yet, I found the following "Note" in the new APW tools manual amusing: "DiskCheck will only verify a ProDos volume. It will not work with an HSF [sic] volume." Now, if this program were named DiskCheckIIGS (implying that it was a port of some MPW tool, like some of the other stuff on the disks), then it would seem to be a bit less indicative of something interesting going on. Why doesn't Apple just have someone who officially "leaks" stuff - that way, Apple would have deniability if something got killed, and it would almost certainly make the rumors more accurate, even considering the "telephone" effect (where things change as they move from mouth to ear...). Of course, they wouldn't be able to leak everything, or else things would return to the way they are today, but people would be complaining about things not existing before the current round of stuff got released. I also seriously doubt that for something like the HFS FST, it would damage any potential edge that Apple would have... > --Dave Lyons, Apple Computer, Inc. | DAL Systems -- Jason Blochowiak - back at school (again). blochowi@garfield.cs.wisc.edu or jason@madnix.UUCP "What's up pruneface?" - Bugs Bunny in the year 2000
mmunz@pro-beagle.cts.com (Mark Munz) (10/10/89)
Network Comment: to #11440 by dlyons@apple.com -> John, I agree with almost everything you said. I just have to point ou -> that *writing* to an HFS volume is more complicated than reading it (si -> you have to rearrange the B-tree (or is it B*-tree?) directory structur -> whenever you add, delete, or rename a file). Bugs in *reading* a disk -> are a nuisance, but any bugs in *writing* could destroy people's volume Wait a sec.. you make it sound like you're GUESSING at how the Macintosh writes its stuff to disk. Last I heard, APPLE had MAC SOURCE on how to read and write to the disk.. Now the way I see it, it would take a very short time for someone to convert the MAC SOURCE CODE into 65816-based code. That's not to say you won't have bugs, but chances are Apple (if they didn't try to do it from scratch) could put out a fairly reliable HFS FST pretty quick like. --Mark Munz
rnf@shumv1.uucp (Rick Fincher) (10/11/89)
At AppleFest recently an Apple Employee let it slip that Apple was working on an HFS FST. We had asked about FST's for the new SuperDrive and he said 'Gee we haven't even shipped the HFS FST for the 800K drives yet and you already want them for the SuperDrive'. We said 'Ah-Haaa so you are working on an HFS FST' and the guy said 'Oops I guess I shouldn't have said that (wink, wink)'. He really spilled his guts then and said that they had been using the HFS FST all over Apple internally for quite a while but it took Apple forever to release stuff like that because they tested it for a long time then documented the final source code, wrote tech notes, modified manuals, etc. etc. All of which takes time. The impression we got was that it was very near to release. I hope Apple doesn't wait for the next major upgrade to GS/OS to ship it. Just include it in new copies of System 5.02, and distribute it through APDA or the online services. We desparately need it. I hope you Apple folks on line will pass this on to the powers that be. Rick