Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0
Message-ID: <3966@internal.Apple.COM>
Date: 29 Aug 89 01:16:27 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 49
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> <8389@hoptoad.uucp> <3943@internal.Apple.C <1413@intercon.UUCP>

In article <1413@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) 
writes:
>  1. No scheme will be perfect in all circumstances.  Life's just like 
that.
>     In fact, I'll posit a strong version of this: Given any scheme for
>     identifying files, there will always be at least one very useful 
operation
>     that will be difficult or impossible.

This strikes me as a truism.  I didn't mean to imply that the new 7.0 file 
system will be the be-all and end-all file system; I just think it's, _in 
general_, better than what we have now.

In article <1413@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) 
writes:
>  2. My biggest problem with the file ID scheme is that it introduces a
>     dichotomy between what the user uses to identify files and what 
software
>     uses.  While this may make some things easier (like aliases and live
>     copy & paste), it is bound to introduce confusion somewhere else.  I
>     think this is a bad thing.  I don't think it's The End Of The 
Macintosh
>     As We Know It :-), but I still think it's a bad thing.

Of course this is a potential problem; I believe that in practice what 
will happen is that people will find that they can do things like rename 
files and move them around (maybe) without software that relies on their 
existence asking so many questions (like "where's that file?").  On the 
other hand, it probably does mean that gone are the days when you could 
kill off that defaults file by sticking an "x" in front of its name or 
what have you.

And you could still write a non-AppleShare AFP server that provided 
consistent dirIDs; you're really just maintaining that associative list of 
IDs with respect to directory names that I mentioned.  There's no reason 
whatsoever for those to change from session to session.  Picture a 
hashtable of directory or pathnames associated with their dirIDs that is 
stored somewhere on the volume and read every time the server comes up.

You're right; if you rely on dirIDs, you'd better be prepared for what 
happens after a backup and restore.  The point is that those are 
infrequent operations by way of comparison with the user renaming a file 
and/or directory, so dirIDs are still the preferred way to go.

___________________________________________________________________________
chewy@apple.com
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
___________________________________________________________________________