Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!apple.com!chewy From: chewy@apple.com (Paul Snively) Newsgroups: comp.sys.mac.programmer Subject: Re: System 7.0 Message-ID: <3943@internal.Apple.COM> Date: 26 Aug 89 00:14:02 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 121 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> In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > WOW!!! What a hole! You actually identify files by NAME instead of by > some invisible token that the user can't get to? Someone call the > cops! > > Did you ever notice that this is also true on every other operating > system? What makes this a deficiency? You quoted my answer later in your post. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > >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]. > > Gosharootie. I hardly know where to start on this. First of all, who > said that was the right way? Apple did, of course, because it is. Full pathnames are most definitely the WRONG way; volumes aren't unique by name, for starters, as they are on UNIX and many other OSes. Obviously directory names aren't unique. Neither are filenames. With a full pathname, there's no way in hell you can guarantee uniqueness. As for remembering dirIDs across fileserver sessions, in actual practice I don't believe that an AFP server (at least) will change them. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Then there's the volume renaming issue you've brought up. It has no > effect in the most common case of needing to get at a file, the > preferences file in the system folder. I don't understand how it is > overcome in other cases by the file id mechanism, since from what I've > seen you need a volume name/file id pair to get at a file. Perhaps I > am mistaken on this point, in which case I hope someone will correct me. Good point--if the only unique way to identify a volume is still by name, then we have accomplished nothing. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Finally, what if you have to remember a file on a network file system? > The full path name will do it, provided the user always mounts the > remote volume from the same point (which is generally the case). Well, > too bad if you want to do it with file ids; they're optional and > probably won't be implemented by many servers, since other operating > systems don't have an analogue. (Sure, there's inode numbers, but > they're not guaranteed to stay invariant given an operation like an > emacs save file.) So you will have to have a menagerie of special > cases in your code. Under 6.0 and earlier, save the full path name. > Under 7.0, save the full path name for network volumes, but the file id > otherwise. What a mess. The server may simpy layer fileIDs on top of the real file management, associating a unique ID with every new file that's made, and providing that ID when the appropriate call is made. That's assuming that nothing will be done to circumvent this associative process in a way that is intrusive to file service, which may or may not be the case; it depends upon how dedicated your server is. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Thanks, but I just ate.... So why do you add worthless features like > directory ids and file ids that are a major pain in the ass for > implementors of network servers on other platforms, if you love them so > much? > > And, by the way, are you saying that you're only happy when someone > implements an AFP server, not a server using some other protocol? > And what about AFP clients? ("You mean you're actually *using* a > non-Macintosh?") Pretty parochial. fildIDs aren't that tough to implement on other systems; it's just that the system might not hand them to you on a silver platter. As for AFP vs. anything else, well, we really want consistent file service, and we've already done the Macintosh AFP client software. I like NFS, too, which is why the existence of the Gator Box is a good thing; the Macintosh user still uses their AppleShare Workstation software that they're accumstomed to, and they see a pretty normal-looking "Macintosh" volume on their desktop, which is as it should be. And that's why we don't encourage writing AFP clients; we already did, and any developer can license it to ship with their product, as Caymen does. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > One last note. It occurs to me that some readers may think I just > haven't worked on any software that would "benefit" from this feature. > One of my current projects is a FAX modem with an envelope interface, > where graphics files are stored in the envelopes. They are currently > stored by full path name. If the user renames them, the user has shot > itself in the foot. Also, if the user throws them in the trash, > there's a hole in that foot, and if the user opens the documents in a > graphics document editor before they can be sent by the background > scheduler, so they're already open when the scheduler tries to send > them, then you're looking at powder burns, flesh wounds, a permanent > limp, etc. You can only protect a user so far before your protection > becomes an unwanted burden, and you can never be completely successful > anyway. Most of us are aware of this in mundane life, but Apple seems > determined to impose this frankly fascist protection-from-yourself-at- > any-cost wherever it can. Thank you for your complete and cogent explanation of precisely why NOT to use full pathnames, etc. We really are trying to look out for the average user, and if here-and-now that means a little more black magic on the part of the developer, well, that's here-and-now. We really do want the Mac to be easy to program, too, but let's face it: it's gonna take a total redesign of our OS to allow that, and I'm just a DTS grunt; I'm not in a position to say if/when we'd ever do such a thing. ___________________________________________________________________________ chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. ___________________________________________________________________________