Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: System 7.0 Message-ID: <8389@hoptoad.uucp> Date: 25 Aug 89 19:46:25 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> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 120 In article <1394@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > AppleShare & the new desktop interface don't use file IDs; it's something > new, and something which I think can only encourage bad programming... > > As for Tim's note, I'm afraid the people working on the Mac file system > simply don't care. It fits into Apple's general attitude towards other > machines doing things that "could be done with Macs": "Why would you want > to do that?" They even take this stand towards some of their own products, > annoyingly enough :-(. > > Grumble. In article <3908@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >I really must take exception to this, because it simply isn't true at all. > 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! >And guess what? The user can change file names anytime s/he wants to! 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? Doesn't it *raise* the level of user insecurity to increase the black box nature of simple operations? Anyone can understand "there's a file named 'Wanderer Preferences' in your system folder"; how many users can understand "There's a file which the program originally created called 'Wanderer Preferences' but which you may have renamed to anything or dragged anywhere but which the system is always keeping track of anyway"? And what does *anyone* gain from the latter case? Whose bright idea was this, anyway? Let's all do our bits to try to ward off the collapse of the Mac OS from terminal "neat-idea-ism". >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? Again, network file systems are not being taken into account. The AFP documentation says that you should not rely on directory ids lasting longer than a session. If you remember it this way now, then you're screwed on any temporary-directory-id AFP server. This is not the right way to do things. Generally, the right way to find a file is to remember only one thing, the file name. Then look for it in the system folder of the boot volume. If you *must* remember a file somewhere else, then save a full path name as a resource. 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. 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. >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). 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. When System 7.0 comes out, I will ignore the file id mechanism, and I suspect many others will do the same; and of course, no existing programs use it. So not only do we have a questionable feature that's used onlu by some programs, but the user has no way of knowing whether a given piece of software will or will not allow renaming. It's a mess for programmers; it's a mess especially for network programmers; it's a mess for users; it's especially a mess for network users. Ditch it now while you still have the chance. 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. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The pride of the peacock is the glory of God. The lust of the goat is the bounty of God. The wrath of the lion is the wisdom of God. The nakedness of woman is the work of God." - Blake, "The Marriage of Heaven and Hell"