Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!rochester!pt.cs.cmu.edu!andrew.cmu.edu!jk3t+ From: jk3t+@andrew.cmu.edu (Jonathan King) Newsgroups: comp.sys.mac.programmer Subject: Re: System 7.0 & Aliases Message-ID: Date: 6 Sep 89 20:06:01 GMT Organization: Psychology, Carnegie Mellon, Pittsburgh, PA Lines: 75 I guess I'm boring too. I mean, I don't go around and rearrange the whole directory structure of my hard disk on a whim, and while aliasing might sometimes be nice, I'm not sure it merits going to Yet Another file system. For applications, I've always wondered why there isn't just a bin directory somewhere where applications really live, period, with, if you like, little aliased icons representing them appearing wherever you want them (over a network, too, I suppose). Then, whenever you try to throw an app away, instead of the "Do you really want to trash App, an application?" dialog you would see "Do you really want to trash App, or just this icon?" with the possible answers "the application", "the icon", or the hilighted "cancel". (I know this dialog text isn't optimal, but I think it's a reasonable idea.) It's too bad that the semantics of the trashcan have gotten as foggy as they seem to be (at least for many users). Of course, the real problem is with documents, as people have been discussing for quite some time. I am envisioning that aliased documents will look just like (and have the same name as) the Real Thing, whatever and wherever that may be, and for all intents and purposes will act like the Real Thing to the user, as long as the user has the appropriate privileges for the document in question. Now things get a little murky. What happens if a user duplicates the Real Thing? A new document is created, with the title "Copy of Real Thing". What if a user duplicates the shimmering simulacrum (alias) of the Real Thing? My guess is that a new copy of the Real Thing is created, entitled "Copy of Real Thing", and that this is NOT an alias. To alias something should probably require the user to explicitly create an alias, even (or particularly) if the document to be aliased is an alias. (When an alias is aliased, there is possibly the question of what the alias points to--I'd vote for the Real Thing, although I can, unfortunately, dream up situations where you might want to make it point somewhere else.) The really hairy problems begin when a user who has access to Real Thing decides to do any of the following: 1) rename Real Thing, 2) trash Real Thing 3) duplicate Real Thing, modify the copy, and then either trash/rename Real Thing and rename the copy as Real Thing, with the belief that this new document will act just like the, uh, real Real Thing; or 4) move Real Thing in the directory hierarchy. What should happen in each of these cases? Here are my answers. When you rename Real Thing, the user should at least be alerted that Real Thing has aliases pointing to it, and offer some different courses of action. A user should be able to arrange it so that either a) the aliases are "updated" appropriately [possibly a really nasty problem] b) the aliases are ignored [which would generate at least a file not found alert for the next user of an alias, unless another file was renamed Real Thing before then]; c) the user's own aliases are wiped out, while others dangle as in (b) [which is probably tricky in some environments]; or d) cancel the action. It's my opinion you have to give the user some choice in the matter. Note in situation (a) that fileIDs look like a win, but this is about the only place they do. If a user trashes Real Thing, then an alert should pop up offering to either a) update the (user's) aliases appropriately [i.e. trash them, too]; b) leave the aliases alone [so the user can rename some other file Real Thing with the expected effects]; or c) cancel the action. I'm not sure how fileIDs would help in accomplishing any of these actions. The scenario where the user tries to switch Real Things by duplicating the original, modifying the copy, trashing the original and renaming the copy is thus already handled by a combination of the above alerts, and can be done without fileIDs. Moving Real Thing in the directory hierarchy would create just the problems that renaming it would, and should generate a similar alert. This could get particularly annoying when you start moving whole folders around. In this case, if the user wants to update aliases on the file(s) in question, he or she should be warned that this could take awhile (if fileIDs don't exist). Note, however, that a user might want to move a file *without* updating its aliases; maybe a new file will be installed in the appropriate folder which should "inherit" those aliases. [Note that this is a potential problem, since the "old" Real Thing has to communicate to the "new" Real Thing where, at the least, its owner's aliases are so that aliases can, if desired, be deleted on request; fileIDs can't help you directly.] So I guess I can imagine a life with aliases and without fileIDs, and that such a life could be, if anything, more flexible for users, less prone to unexpected glitches, and more likely to provide the Real Thing. jking