Path: utzoo!attcan!uunet!intercon!amanda@intercon.uu.net
From: amanda@intercon.uu.net (Amanda Walker)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0
Message-ID: <1402@intercon.UUCP>
Date: 25 Aug 89 04:21:54 GMT
References: <227700026@uxa.cso.uiuc.edu> <483@sunfs3.camex.uucp> <9173@thorin.cs.unc.edu> <13784@shamash.cdc.com> <490@sunfs3.camex.uucp> <8368@hoptoad.uucp> <3214@zeus.unl.edu> <1394@intercon.UUCP> <3908@internal.Apple.COM>
Sender: news@intercon.UUCP
Reply-To: amanda@intercon.uu.net (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 51

In article <3908@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes:
>  The rationale around providing fileIDs is actually to correct a glaring 
> deficiency in all existing Macintosh file systems, namely that the only 
> way to uniquely identify a file right now is--guess how?--the file name!

Which is how the rest of the world does it, by and large...  So?
  
> And guess what?  The user can change file names anytime s/he wants to!  So 
> if your program keeps track of where a file is the "right way" (Volume 
> name/dirID/file name), you're screwed if the user changes the name of the 
> volume or the name of the file, and you have to "locate" the "lost" file, 
> even though the thing may not have moved so much as a pixel in its Finder 
> window.  [sigh].

So we attach magic cookies so that it's the file's *history* that counts,
not it's name or location?  Bad magic, kemosabe.  I doubt I'm the only one
who temporarily renames files (usually settings files, which are prime
candidates for File IDs) to "move them out of the way" for a bit.  With File
IDs, I'll have to duplicate the file and throw out the old copy, and then ...
what happens when I want to put it back [:-)/2]?

> As for implementation on other platforms, actually, we're quite pleased 
> when someone implements an AFP server on another platform, such as CAP or 
> the Gator Box from Caymen systems (even if it is slow; YOU try doing 
> NFS/AFP protocol translations on the fly sometime).

Well, they don't exactly...  Technically, they have written an AFP server that
uses NFS as its native file system.  A nifty feat, all in all, mainly because
of the bizarreness of the Macintosh file system.  One of the big wins of
the new desktop calls under AFP was that you could actually implement AFP
on a foreign platform without having to actually store away Directory IDs
for the Finder.  With File IDs, we'll have to go back to maintaining a
parallel directory structure again.  Bleah :-P

I can see implementing something like File IDs to make things like the
Publication stuff and live copy & paste easier in the presence of files
being renamed.  But in my opinion, making it yet another basic file system
feature is silly.

It was probably relatively easy to add to HFS, which uses B*-trees as
directories, but I find it hard to believe that you worried at all about
how difficult it would be to implement on non-Macs.

I'm not sure this is exactly a bad thing--I mean, designing Mac software
is Apple's job, and designing other stuff is ours, but still, it's aggravating.

--
Amanda Walker
InterCon Systems Corporation

amanda@intercon.uu.net    |    ...!uunet!intercon!amanda