Bruce.Hoult@bbs.actrix.gen.nz (01/29/91)
ned.horvath writes: >The OS proper is the moral >equivalent of floor sweepings, and the ugliness of HFS and MultiFinder >are the result. What's so ugly about HFS? I don't see any problems with the programming interface to it, and it looks to be a pretty good implementation of a high-performance file system -- the use of a volume allocation bitmap, and file extent and directory b*-trees in particular enable much better performance than the schemes in many other operating system (such as MS-DOS and Unix, for example). The Desktop file is ugly, but that's not part of the file system (it's a *use* of the FS) and it's disappearing anyway. The PMSP is ugly but can easily be avoided. What other problems are there? -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ "And they shall beat their swords into plowshares, for if you hit a man with a plowshare, he's going to know he's been hit."
jmunkki@hila.hut.fi (Juri Munkki) (01/30/91)
In <1991Jan29.074646.7218@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: >ned.horvath wrote: >>The OS proper is the moral >>equivalent of floor sweepings, and the ugliness of HFS and MultiFinder >>are the result. > >What's so ugly about HFS? I don't see any problems with the programming >interface to it, and it looks to be a pretty good implementation of a >high-performance file system -- the use of a volume allocation bitmap, and >file extent and directory b*-trees in particular enable much better >performance than the schemes in many other operating system (such as >MS-DOS and Unix, for example). HFS performs ok, but it has a really nasty progrmming interface. Unless you are just using SFGetFile and SFPutFile, you need to know about directory id numbers, working directory reference numbers and all the garbage that goes with them. Assume for instance that the user opens a document. To do this, a file is selected and the program now has a working directory number and a file name. The program opens, reads and closes the file (no problem here). The user then edits the file and wants to save. The program still only has the working directory reference number, which at this time might no longer be valid. (I might be wrong here, so please correct me. I've never really understood when and how the numbers are allocated and deallocated. I know they will not be deallocated, if a file is open, but I think the latest guidelines say that files should not be left open.) Another interesting scenario involves copying a file. The only true way to do it involves opening and reading the resource and data forks and the finder info. It's a lot of work, if you want to do it reliably. Of course, the latest file system _might_ support a file copying trap. This trap of course works only on AppleShare volumes. Apple didn't bother implementing it on local disks (at least I never got it to work). Another silly limitation is that you can only copy or move a file within a single volume. As long as things are relatively simple, everything is nice and easy. The IM-II file manager chapter is actually quite readable and can even be understood with relative ease. The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do. Then there is of course the IM-V documentation for appleshare volumes (you can't skip that, can you?) and the next Inside Macintosh some some new hacks and kludges installed to make the programmers life easier (assuming that the progrmmer is happy to run only with system 7.0). AppleTalk and the File Manager are the worst parts of programming a Mac. What I would really like in a file system would the capability of making a file appear as an area in RAM. I think this has been implemented with Mach and it would be a very nice addition to any OS. Unfortunately it does require a MMU, so as long as the Classic Mac is alive, there's no chance of it getting implemented on the Mac. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/30/91)
In article <1991Jan29.074646.7218@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: >What's so ugly about HFS? I don't see any problems with the programming >interface to it To quote an early Apple manual, "You are a mutant, and will go far in the computer world." You like working directory reference numbers? You like knowing when you should, must, and must not use them? You like knowing when you should, must, and must not close them? You like checking to see if HFS is active? You like the fact that the high-level calls are incredibly wimpy, and the PB calls use the Parameter Block From Hell? You like the fact that PBGetCatInfo changes the dirId field on you if you happen to be looking at a directory? (Fun for indexed calls, folks!) None of these can't be programmed around. But that means that every application has extra code in it, to produce high-level calls that ought to be in the system. It also means that every developer has to wade through IM-IV, and all the debugging involved with writing these sorts of things. One of my favorite bugs was forgetting to set ioMisc in a PBHOpen call. Seems ioMisc is ignored on newer machines, 'cause I didn't have any problems. Watch out on an SE or older, though... This kind of thing is very easy to do, but could be avoided with a smarter high-level interface than FSOpen (like, let me specify a dirId, and what permissions I want; who cares about an alternate volume buffer?). Whine, whine, whine, I know. But I've been bitten often enough by the File manager to have developed a distinct distaste for it. I'm glad to hear that system 7 addresses these issues. Of course, that's not much use since a heck of a lot of macs won't be running system 7 for a heck of a long time. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
keith@Apple.COM (Keith Rollin) (01/31/91)
In article <1991Jan29.074646.7218@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: > >ned.horvath writes: >>The OS proper is the moral >>equivalent of floor sweepings, and the ugliness of HFS and MultiFinder >>are the result. > >What's so ugly about HFS? I don't see any problems with the programming >interface to it, and it looks to be a pretty good implementation of a >high-performance file system -- the use of a volume allocation bitmap, and >file extent and directory b*-trees in particular enable much better >performance than the schemes in many other operating system (such as >MS-DOS and Unix, for example). I think that a lot of people don't like HFS because they are confused about the roles working directories and default directories play. They see these things documented in Inside Mac, and think they have to use them. To make my own life simple, I follow these simple rules: - DON'T USE WORKING DIRECTORIES. They're simply not needed. However, as with any general rule, there are two minor exceptions. If you make a Standard File call, you will recieve a WD refnum. Immediately call GetWDInfo and turn this into a real vRefNum/dirID pair. The second exception is when you are sublaunching another application. You need to create a WDRefNum for the application you launch. - DON'T USE DEFAULT DIRECTORIES. Ever since 1986, you've been able to fully specify a file in whatever File Manager or Resource Manager call you are interested in making. The only exception to this is, again, when you are sublaunching another application. You need to do a SetVol() with a WDRefnum so that the launched application can to a GetVol() and find out where it is. When I follow those rules, I rarely run into problems (the only other problems involve wondering if I should put a colon after a string when I want to refer to a directory, or what is returned in the various "parID" fields on GetCatInfo and GetFInfo calls). I never sub-launch other programs, so the only time I have to deal with working directories is when I make a Standard File call...and I don't deal with them for long because I immediately get the real vRefNum and dirID. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
minich@unx2.ucc.okstate.edu (Robert Minich) (01/31/91)
by jmunkki@hila.hut.fi (Juri Munkki): | Assume for instance that the user opens a document. To do this, a file | is selected and the program now has a working directory number and a file | name. The program opens, reads and closes the file (no problem here). The user ^^^^^^^^^^^^^^^^^^^^^^^^^========== | then edits the file and wants to save. The program still only has the | working directory reference number, which at this time might no longer | be valid. (I might be wrong here, so please correct me. I've never really | understood when and how the numbers are allocated and deallocated. I know | they will not be deallocated, if a file is open, but I think the latest | guidelines say that files should not be left open.) You should keep the file open if the user can edit it. This _is_ in IM and is a major requirement for using shared volumes. With your approach, to users can have the same file "open" at the same time and make different changes of which only one user's get's saved. | Another interesting scenario involves copying a file. The only true way | to do it involves opening and reading the resource and data forks and | the finder info. It's a lot of work, if you want to do it reliably. What's so hard about it? What "lot of work?" If this is hard, you probably have lots of other problems ahead of you. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm not discouraging others from using |=(___)= | minich@d.cs.okstate.edu | their power of the pen, but mine will | U | - "Ackphtth" | continue to do the crossword." M. Ho
d88-jwa@dront.nada.kth.se (Jon W{tte) (02/01/91)
In article <> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >You like checking to see if HFS is active? You like to program for machines with < 512k for System AND application AND data ? Try MS-DOS ! What's the market anyway ? >You like the fact that the high-level calls are incredibly wimpy, and the >PB calls use the Parameter Block From Hell? >to do, but could be avoided with a smarter high-level interface than >FSOpen (like, let me specify a dirId, and what permissions I want; who HOpen ? It works with systems >= 4.2... h+ :::::::: Jon W{tte, Stockholm, Sweden, h+@nada.kth.se :::::::: "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki (jmunkki@hut.fi) in comp.sys.mac.programmer