Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!julius.cs.uiuc.edu!apple!heksterb
From: heksterb@Apple.COM (Ben Hekster)
Newsgroups: comp.sys.mac.programmer
Subject: The Beauty of HFS
Message-ID: <48627@apple.Apple.COM>
Date: 29 Jan 91 23:10:11 GMT
References: <1991Jan25.213652.26781@cbnewsk.att.com> <1991Jan29.074646.7218@actrix.gen.nz> <1991Jan29.174321.19621@santra.uucp>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 68

In <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, 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).

jmunkki@hila.hut.fi (Juri Munkki) writes:

> 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.

It's not all that difficult.  There are basically two strategies you can
pursue-- either you keep the working directory reference number around and
stick to the MFS calls, or use _GetWDInfo immediately whenever you get a
working directory reference number and just work in terms of volume reference
numbers and directory IDs.

> 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.)

I'd think we can safely assume the working directory reference number will
remain valid while the application is running...  but again, if you were
really worried about it, why not convert the working directory reference
numbers and forget about them altogether?

> 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.

Again, it's really not all that difficult.  The basic fork-copying algorithm
involves allocating a buffer and looping _Read and _Write calls, which works
for every case.  You get to use the same code for both forks.  For really
efficient file copying, you can vary the size of the buffer according to the
amount of memory you have.

[_CopyFile]
> 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.

Using _CopyFile on shared volumes is useful because you avoid the redundant
network traffic caused by what is basically the application echoing the entire
file back to the shared volume, and the one server can handle the call.  In
fact, _CopyFile does work on different volumes when they are both on the same
server.  For it to work between servers would require the shared volume to
communicate with other servers and wouldn't eliminate the network traffic of
file copying, so would give you little (if any) savings over the basic copying
loop.

_______________________________________________________________________________
Ben Hekster                           | "I've had my fun
Student intern                        |  but now it's time
AppleLink:   heksterb                 |  to serve your conscience
Internet:    heksterb@apple.com       |  overseas"
BITNET:      heksterb@henut5          | --Orange Crush, R.E.M. (Green)