Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!widener!ukma!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!udel!wuarchive!usc!apple!apple.com!rmh From: rmh@apple.com (Rick Holzgrafe) Newsgroups: comp.sys.mac.system Subject: Re: Alias resolution: right or wrong? Message-ID: <13808@goofy.Apple.COM> Date: 31 May 91 21:25:31 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 64 Aliases keep a fairly comprehensive collection of information about the original file. When it's time to resolve the alias and find the original, the Alias Manager uses a set of heuristics: it tries the "canonical" thing first, then if that fails it tries a succession of less likely (and perhaps slower) methods, using some of the extra info. The canonical "address" of a file is a triplet of . This is the method of choice (here I'm guessing! I'm not a guru on this) because folderIDs are unique (forever) among all folders on the volume, and it's a fast lookup method, and it is immune to things like renaming any folders above the file, or moving the parent folder within the volume. This is why the original poster (Eric J. Baumgartner, I think) found that an identically-named *copy* of his original file, kept in the original folder, was the file found by the alias (instead of the actual original, which had been moved elsewhere). The trouble is that there is *no* way to uniquely identify a file under all the transformations it can undergo. The original can be renamed, or moved, or its parent folder(s) renamed or moved, or it can be deleted and restored from backup, or replaced during a save. (That last is standard for a well-written app: if there's enough disk space, you save to a *new copy*, and when that's complete, you delete the original and rename the new copy.) So how do you uniquely identify a file under all these circumstances? The "logical" file's name, parentage, fileID, size, and location all can change. The alias manager can successfully find the original file under *all* these transformations. But it can't do it if they all change at once, and (as you've found) it can be fooled if a sufficiently convincing changeling is left in the original's place after the original is moved elsewhere. Under the circumstances, I think the Alias Manager did the right thing in Eric's case. Although it found a copy instead of the original, the file it chose was the one he wanted: the one in the original folder, not the one in his backup folder. This tells me that the folks who designed the Alias Manager made some pretty good decisions. > Can anyone > explain the semantics of this and why it isn't going to land someone > in trouble? I've hand-waved at the semantics above. I doubt it will get many people in trouble, since most files actually don't move much. When they do, it's innocuous stuff like a name change or a move, that the Alias Manager handles correctly. I haven't seen a scenario yet where the Alias Manager would actually come up with the "wrong" file in a practical rather than technical sense. (Do you see what I mean? Eric felt that it hadn't found the "technically correct" file, but agreed that it did find the one he really wanted.) I'm not saying that it never can or never will make an annoying or damaging mistake. I just think it's very unlikely, and will require some fairly exceptional circumstances. ========================================================================== Rick Holzgrafe Unabashed apologist | {sun,voder,nsc,mtxinu,dual}!apple!rmh for Apple :-) | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."