Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!funic!santra!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Beauty of HFS
Message-ID: <1991Jan30.234817.9430@santra.uucp>
Date: 30 Jan 91 23:48:17 GMT
References: <1991Jan25.213652.26781@cbnewsk.att.com> <1991Jan29.074646.7218@actrix.gen.nz> <1991Jan29.174321.19621@santra.uucp> <48627@apple.Apple.COM>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 55

In article <48627@apple.Apple.COM> heksterb@Apple.COM (Ben Hekster) writes:
>jmunkki@hila.hut.fi (Juri Munkki) writes:
>[_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.

My point was that it shouldn't be the programmers job to check for a file
server and use the trap if is allowed and different code if it doesn't. The
file system knows about these things much better than the poor programmer
that is struggling to understand HFS. So what if there is no saving? There's
no harm done either, if the trap knows how to do a simple copy. Of course
this would also allow Apple to upgrade server code so that when copying is
from one file server to another, the client node is not used.

The weakness about WDRefNums and directory IDs is that the documentation
first talks about the other and then about the other. If I'm scanning
through IM IV, I probably only want to know about one or the other. I
get the same feeling I got when I tried to learn Apple II basic, but
didn't notice that I had been given two basic books: one about AppleSoft
and the other about Integer basic. It was and is confusing.

I'm not saying that I can't handle the File Manager. I'm only saying that
I didn't have any problems with MFS calls (back in the days when there
wasn't anything else) and I had a lot more trouble when HFS arrived.

Recently I wanted a program that automatically copies files that were
changed and I tried using the new file copying operation. Of course I
installed AppleShare, but I learned that it didn't work on my hard disk
only after an hour or two of struggling with the parameter block.

I've heard that System 7.0 will improve things. I hope it does.
I'll get IM-VI when it is published. I used to care enough to
get beta documentation, but nowadays I don't have the time
to bother with that.

I think that the file manager should be as intelligent and object
oriented as possible. With object oriented I mean that the same calls
should apply to files, folders and volumes. The same file copying
command could quite well support all those objects.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~