mlwiese@mit.edu (04/08/91)
Note: Flame ahead I was disappointed to discover that aliases in 7.0 are only an illusion presented by the Finder and StdFile. This means that NO application is 7.0 compatible without a rewrite to support aliases, IMO. Yeah, aliases are a new feature, but I expected them to work everywhere and so will a lot of other users. Will someone please tell me why the OS can't intercept a file system call dealing with an alias and automatically resolve the alias? Sure, some disk editing apps might break, but better a few of them than ALL apps. Mike
james@netcom.COM (James L. Paul) (04/08/91)
In article <1991Apr7.221543.3719@athena.mit.edu> mlwiese@mit.edu writes: >Note: Flame ahead > >I was disappointed to discover that aliases in 7.0 are only an illusion >presented by the Finder and StdFile. This means that NO application is 7.0 >compatible without a rewrite to support aliases, IMO. Yeah, aliases are a new >feature, but I expected them to work everywhere and so will a lot of other >users. > >Will someone please tell me why the OS can't intercept a file system call >dealing with an alias and automatically resolve the alias? Sure, some disk >editing apps might break, but better a few of them than ALL apps. > >Mike Could you clarify this a bit? I haven't had any problems with aliases. In every case I have tried, an alias behaves just like the original file, similar to a unix symlink. Even over a network, accessing a published alias on another mac hasn't seemed to be a problem. I have aliases of many applications in my Apple Menu Items folder. There's no problem getting QuickKeys to use aliases, either. All my applications seem to use aliases just fine, just as if they were working with the original file. The alias files created are not illusions, as far as I can tell. They are real files about 2k in size, with the "alias bit" set, so that the system knows that that alias is not the actual file, but a file reference. I haven't run into any cases yet where something needs to be rewritten to support aliases. What doesn't work with aliases? In what way do you consider them to be an illusion? You say that NO applications work with them... In what way do applications fail to work with aliases? You say they do not work everywhere. Where do you find them to fail? I'm asking out of curiosity. My experience with aliases sounds different from yours. I'm running 7.0FC1. I'd appreciate an example where the illusory nature of aliases can be demostrated. -- James L. Paul Internet: netcom!james@apple.com | AppleLink: D1231 | CompuServe: 72767,3436 UUCP: {apple,amdahl}!netcom!james | GEnie: J.PAUL | Voice: 415 377-1981 Packet: N6SIW@N6EEG.CA.USA.NA | Delphi: JLPaul | Home Fax: 415 377-0381
macman@wpi.WPI.EDU (Chris Silverberg) (04/08/91)
In an article mlwiese@mit.edu rambles: >I was disappointed to discover that aliases in 7.0 are only an illusion >presented by the Finder and StdFile. This means that NO application is 7.0 >compatible without a rewrite to support aliases, IMO. Yeah, aliases are a new >feature, but I expected them to work everywhere and so will a lot of other >users. I'm not sure I understand what you mean... yes, the alias is really just a simple 1k file, but you'd never notice this unless you go back to System 6. For instance, ANY program that displays an open file box will access the real file when you select the alias... automatically... it doesn't matter WHEN they were written. Even things like Disktop will launch or open an alias correctly... Programs that perform disk management type stuff will likely need to be updated for various reasons when system 7 comes out, but it's fairly simple from the programmer's point of view to recognize the new features of 7. - Chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Silverberg INTERNET: macman@wpi.wpi.edu Worcester Polytechnic Institute Main Street USA 508-832-7725 (sysop) America Online: TfChris WMUG BBS 508-832-5844 (sysop)
psych@watserv1.waterloo.edu (R. Crispin - Psychology) (04/08/91)
In article <1991Apr7.221543.3719@athena.mit.edu> mlwiese@mit.edu writes: >Note: Flame ahead > >I was disappointed to discover that aliases in 7.0 are only an illusion >presented by the Finder and StdFile. This means that NO application is 7.0 >compatible without a rewrite to support aliases, IMO. Yeah, aliases are a new >feature, but I expected them to work everywhere and so will a lot of other >users. > >Will someone please tell me why the OS can't intercept a file system call >dealing with an alias and automatically resolve the alias? Sure, some disk >editing apps might break, but better a few of them than ALL apps. > >Mike I don't understand what kind of problem you are having. I copied a bunch of applications onto a system 7.0 equiped drive and made aliases for many of them. I installed some so they would show up in the DA menu. Others I put in folders where it would be handy to have the applications. They all worked fine. These were not system 7.0 applications. As far as I can tell applications don't need to be changed to work using aliases. The system/finder was changed to support them. If I am missing something let me know. Richard Crispin Phone: (519)888-4781 Dept. of Psychology EMail: psych@watdcs.uwaterloo.ca University of Waterloo psych@watserv1.uwaterloo.ca Waterloo, Ont. Canada N2L 3G1
dorner@pequod.cso.uiuc.edu (Steve Dorner) (04/09/91)
In article <1991Apr8.013825.13118@netcom.COM> james@netcom.COM (James L. Paul) writes: >I'm asking out of curiosity. My experience with aliases sounds different >from yours. I'm running 7.0FC1. I'd appreciate an example where the illusory >nature of aliases can be demostrated. How many applications can deal with their 'Preferences' or 'Settings' files being aliases? MacTCP's dnr looks for itself in the system folder; will it accept an alias? I'd imagine the answers are none (except for those few sys7 aware apps) and no. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
hamilton@kickapoo.cs.iastate.edu (Jon Hamilton) (04/09/91)
dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <1991Apr8.013825.13118@netcom.COM> james@netcom.COM (James L. Paul) writes: >>I'm asking out of curiosity. My experience with aliases sounds different >>from yours. I'm running 7.0FC1. I'd appreciate an example where the illusory >>nature of aliases can be demostrated. >How many applications can deal with their 'Preferences' or 'Settings' files >being aliases? Am I missing something here? Prefs and Settings go in their respective folders in the system folder, right? Why would you ever want to use an alias for one? >MacTCP's dnr looks for itself in the system folder; will it accept an alias? >I'd imagine the answers are none (except for those few sys7 aware apps) and no. >-- >Steve Dorner, U of Illinois Computing Services Office >Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner -- Jon Hamilton hamilton@kickapoo.cs.iastate.edu " I feel a lot more like I do now that I did before I got here " - can't remember who
dorner@pequod.cso.uiuc.edu (Steve Dorner) (04/09/91)
>Am I missing something here? Prefs and Settings go in their respective folders >in the system folder, right? Why would you ever want to use an alias for one? Suppose you never back up the drive that your system folder is on, but you want to back up your settings files. Suppose you DON'T want to back up settings files, and want to name them something DiskFit won't back up by putting []'s around them. Suppose you want to have one copy of a settings file on a file server, and point all macs in a lab to it. None of those things is unreasonable, and all of them could be accomplished if the "*open*" traps resolved aliases for the programmer. But, all of these things will take new code in every app, which is too bad. If this was a technical decision, taken because the other direction would have caused too many problems, I can understand. If it was the result of a "We KNOW that faking this with Standard File is just as good as doing it in the file manager," then I beg to differ. End of the world? No. Pain in the tuckus? Yes. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Jim.Matthews@dartmouth.edu (Jim Matthews) (04/09/91)
In article <1991Apr8.215943.6159@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) write: >> Am I missing something here? Prefs and Settings go in their respective folders >> in the system folder, right? Why would you ever want to use an alias for one? > > Suppose you never back up the drive that your system folder is on, but you > want to back up your settings files. I think this actually gets at one reason why aliases aren't handled transparently by the file system. If they were, I don't see how you could allow aliases that cross volume boundaries, or even point to other folders. The Mac file system is a forest, and allowing volumes to sprout from within other ones would greatly complicate the file system model. There's no way for PBGetCatInfo to let you know that a folder you've entered not only has a new directory id, it has a new volume refnum. Aliases to folders on the same volume can cause cycles, and break existing software. For example, my FTP client lets you upload folder hierarchies, which it traverses with a standard recursive approach. Today I know that the process will terminate; with aliases I might run into a cycle, and upload forever. The authors of archivers, virus-checkers, file-finders, etc. would be in the same boat. Plus, it would be a bit unseemly for HFS to be keeping AppleShare passwords and whatnot in file system data structures. 7.0 Aliases are more complicated and versatile than a file system directory entry, and there's room for them to grow (and become *more* complicated :-). So concientious Mac programmers will have to put calls to ResolveAlias in all the right places. And isn't doing things by hand what Mac programming is all about? :-) Jim Matthews Dartmouth Software Development --
lsr@Apple.COM (Larry Rosenstein) (04/09/91)
In article <1991Apr8.174933.10818@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >How many applications can deal with their 'Preferences' or 'Settings' files >being aliases? What would be the point? Preferences files are already stashed in a special folder and the only thing you ever do with them is throw them away. >MacTCP's dnr looks for itself in the system folder; will it accept an alias? The code to access the dnr is linked into every application, I believe. So you could resolve the alias if you wanted to. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
lsr@Apple.COM (Larry Rosenstein) (04/09/91)
In article <1991Apr8.215943.6159@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >None of those things is unreasonable, and all of them could be accomplished >if the "*open*" traps resolved aliases for the programmer. You are right that none of these things seem unreasonable. But there are other issues with automatically resolving aliases. For every case where you want your backup program to resolve aliases, there would be cases where you didn't want this because you would end up backing up the same file twice. (I keep aliases to applications for convenience, so backing up an app twice would be a large expense.) Resolving an alias can require mounting a file server, which may involve asking for a password. This could impact when and _Open call would be legal. >If this was a technical decision, taken because the other direction would >have caused too many problems, I can understand. If it was the result of I think that's the case. There are a lot of cases where it might make sense to automatically resolve aliases, but I think you would also find a lot of problems arising if you started to do that. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)