oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/23/89)
In article <490@sunfs3.camex.uucp> kent@sunfs3.UUCP (Kent Borg) writes: >`Aliases', as they are calling them, are implemented as a >little file which has the volume name and file id (itself a new 7.0 >feature) of the actual file. Note, this means that your Save command had better write the data back into the original file, and not into some newly created file that it will rename if the write succeeds. (if it destroys the original in the course of the save, it will disconect any aliases that file might have.) How many programs do a delete before the save? How many don't catch the fact that delete uses the poor man's search path, so if you try to create a document named "Finder" a side effect is to delete the Finder? Programmer beware! Programer take care! --- David Phillip Oster --"Unix Version 7 was an improvement not Arpa: oster@dewey.soe.berkeley.edu --only over its predeccessors, but also its Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --successors."
tomc@mentor.com (Tom Carstensen) (08/24/89)
oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: > Note, this means that your Save command had better write the data back > into the original file, and not into some newly created file that it will > rename if the write succeeds. (if it destroys the original in the course > of the save, it will disconect any aliases that file might have.) Whay about backup files. My application has an option to create .bak files whenever the user manually saves a file. The .bak is created by renaming the disk file foo to foo.bak, and then creating and writing out an up-to- date file does this mean the alias will point to the .bak file, and the new file will lose the alias. It seems that this implementation of aliases is far to error prone (why not stick to more conventional methods, like keeping the directory ID and filename or, if you like Unix, the path name). :-------------------------------------------------------------------------: : | GEnie: T.CARSTENSEN | tomc@pdx.MENTOR.COM : : Thomas | Delphi: CARSTENSEN | ...{sequent,tessi,attunix, : : Carstensen | CompuServe: 73627,2762 | apollo}!mntgfx!tomc : : | AppleLink: D3852 | : :-------------------------------------------------------------------------:
kent@sunfs3.camex.uucp (Kent Borg) (08/24/89)
In article <30837@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <490@sunfs3.camex.uucp> kent@sunfs3.UUCP (Kent Borg) writes: >>`Aliases', as they are calling them, are implemented as a >>little file which has the volume name and file id (itself a new 7.0 >>feature) of the actual file. > >Note, this means that your Save command had better write the data back >into the original file, and not into some newly created file that it will >rename if the write succeeds. (if it destroys the original in the course >of the save, it will disconect any aliases that file might have.) > >How many programs do a delete before the save? How many don't catch the >fact that delete uses the poor man's search path, so if you try to create >a document named "Finder" a side effect is to delete the Finder? > >Programmer beware! Programer take care! As I understand it, aliases are implemented as a charade put on by the standard file dialogs and the Finder. When user says "Open...", and in the open file dialog selects an alias file, then clicks "OK", the reply record will be filled in with the details of the *actual* file (mounting a needed AppleShare volume if needed), as if the user had actually gone and opened that file. The application never sees the alias file or its directory. The Finder will do about the same. If the user double clicks on an alias file, the Finder will find the real thing and pass info about it to the application. (I don't know about icons for aliases. I guess that they might be just like the icon of the actual file, but with some regular adornment like a gray drop shadow??) One problem I see with aliases will be for people who have hacked the standard file dialog. What if you want to access the file in a hook routine? Maybe you are displaying a thumbnail sketch of a large image and need to look at a low resolution version you left in a resource. What will you see at hook time? Will delete still use the Poor Man's Search Path? I don't know. I do know that Apple is working very hard to not break old programs. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
peirce@claris.com (Michael Peirce) (08/25/89)
In article <1989Aug23.180141.16033@mentor.com> tomc@mentor.com (Tom Carstensen) writes: >> Note, this means that your Save command had better write the data back >> into the original file, and not into some newly created file that it will >> rename if the write succeeds. (if it destroys the original in the course >> of the save, it will disconect any aliases that file might have.) > My understanding was that save/rename would still be the preferred Save command technique. System 7 would provide a SetTheFileIDPlease call so that the the sequence would become something like (1) save new file, (2) get old file ID, (3) delete old file, (4) set new file's ID to the old file's ID. Of course system 7 is always subject to change and the above is remembered from info gathered at the developer's conference. Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
lsr@Apple.COM (Larry Rosenstein) (08/26/89)
In article <10516@claris.com> peirce@claris.com (Michael Peirce) writes: > technique. System 7 would provide a SetTheFileIDPlease call so that the > the sequence would become something like (1) save new file, (2) get old file > ID, (3) delete old file, (4) set new file's ID to the old file's ID. The preliminary documentation describes a call to exchange the contents of 2 files while retaining their ids. I don't know if this is still the approach being taken. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
asg@pyuxf.UUCP (alan geller) (08/31/89)
OK, OK, OK. So far I've read dozens of complaints about Apple implementing file aliases using 'file ids'. Many of the complaints have mentioned how terrible this is, especially compared to what Unix does. WHAT DO YOU THINK AN INODE IS, PEOPLE?!?!?!?!?! That is, Unix directory entries contain a file name and an inode number. The inode number is an index into the filesystem's inode table, which is a big array of inode data structures that live at the front (usually) of the filesystem. The inodes contain the actual file block pointers. That is, if you have two files, A and B, which share an inode, and use an editor on A which renames A to A.bak and creates a new file named A with the results of your edit, ... A.bak and B are the same (share an inode), and A is totally different!!! Isn't this exactly what Apple is talking about? Now, if this is really such a problem, why hasn't it been such a problem in Unix? Sure, for situations such as the above, you (the programmer) have to think ahead, so that you (the user) don't get confused: you have to copy A to A.bak, truncate A, and then write the new file out to A, thus maintaining the link between A and B. And apparently Apple is even going to give us a call that will flip two file's contents, so that all you have to do is write a new file and flip the new A and the old A! Let's look at this another way. Given the ability to rename files, so that pathnames are not sufficient for permanently identifying files; given that file icons can be moved, so screen icon location is no good; files can move from folder to folder, so folder plus relative position in folder is no good; and so on, what is a better way to permanently identify the 'file' that is shared between two different path aliases? Answer that, and THEN flame -- or write the great American OS, instead. Alan Geller Bellcore I have no association with Apple, other than as a very satisfied user.
amanda@intercon.uu.net (Amanda Walker) (09/02/89)
In article <561@pyuxf.UUCP>, asg@pyuxf.UUCP (alan geller) writes: > WHAT DO YOU THINK AN INODE IS, PEOPLE?!?!?!?!?! So, like, what system call do you use to open a file by inode number under UNIX? I must have missed it sometime in the past 8 years... The only way to do it is by doing a tree walk of the entire file system, which is a much worse idea than maintaining a parallel directory structure. If you don't think so, try it. On a large file-server-size filesystem. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
blm@6sigma.UUCP (Brian Matthews) (09/02/89)
In article <561@pyuxf.UUCP> asg@pyuxf.UUCP (alan geller) writes: |OK, OK, OK. So far I've read dozens of complaints about Apple implementing |file aliases using 'file ids'. Many of the complaints have mentioned how |terrible this is, especially compared to what Unix does. |WHAT DO YOU THINK AN INODE IS, PEOPLE?!?!?!?!?! Oh, which system calls in Unix take inode numbers? |Let's look at this another way. Given the ability to rename files, so that |pathnames are not sufficient for permanently identifying files; Uh, who said they wanted to permanently identify files? I certainly didn't. -- Brian L. Matthews blm@6sigma.UUCP Six Sigma CASE, Inc. +1 206 854 6578 PO Box 40316, Bellevue, WA 98004
allbery@NCoast.ORG (Brandon S. Allbery) (09/04/89)
As quoted from <561@pyuxf.UUCP> by asg@pyuxf.UUCP (alan geller): +--------------- | OK, OK, OK. So far I've read dozens of complaints about Apple implementing | file aliases using 'file ids'. Many of the complaints have mentioned how | terrible this is, especially compared to what Unix does. | | WHAT DO YOU THINK AN INODE IS, PEOPLE?!?!?!?!?! +--------------- Alan, you've been confused by a mistake in terminaology. These folks who claim to be talking about "Unix" aren't -- they're talking about Berklix, and (in particular) about a certain kluge known as a "symbolic link". [ 1/2 ;-) ] ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu "Why do trans-atlantic transfers take so long?" "Electrons don't swim very fast." -john@minster.york.ac.uk and whh@PacBell.COM
ech@cbnewsk.ATT.COM (ned.horvath) (09/04/89)
In article <561@pyuxf.UUCP>, asg@pyuxf.UUCP (alan geller) writes: > WHAT DO YOU THINK AN INODE IS, PEOPLE?!?!?!?!?! From article <1430@intercon.UUCP>, by amanda@intercon.uu.net (Amanda Walker): > So, like, what system call do you use to open a file by inode number > under UNIX? I must have missed it sometime in the past 8 years... Thanks, Amanda. Also, Apple's fileIDs are never reused; inodes are reused, generally right away (the typical unix kernel caches a short list of available inodes in each volume's superblock). If anyone tries to implement fileIDs as inumbers there are some ugly bugs ahead. Indeed, Tim Maroney's original broadside remains unanswered. To distill his lengthy remarks: 1. What good are these things? What can "reference by fileID" accomplish that "reference by pathname" cannot? 2. More importantly: what impact do these "programmer only" names have on the end-user's mental model? Truth be told, I haven't seen or dreamed up any good answers for 1. I'm not looking for a "can to you do THIS?" wars. I actually thought of a few candidates, but I rather easily shot 'em all down: - it simplifies life for the Finder/Desktop manager: once I've found an application, I can always find it again without a disk search. But given the new fast-directory-search in 7.0, who needs it? - it simplifies finding your preferences file. This is plain silly: where do you keep the fileID of the preferences file? - it allows you to atomically replace a large object (database, application, etc.). But renaming is just as atomic, and both depend on the directories being atomically updated to the disk. This is a hole in the present scheme: I spent an afternoon weaving a volume catalog back together when everything lexically later than "foo" vanished one day. This is a definite bug, and one that is only helped by (well-known) btree update techniques. - it allows you to grant access to an object via an alias, and later deny access to that same object. Symbolic links will do as well for this use, too. As for the second question -- what's the impact on the end user -- I suspect that the likelihood of confusion is low if fileIDs are used judiciously. But that's a big if. About the only gain I see is that the next round of HyperCard won't need to ask where you hid the Help stacks more than once. If Everyman is really going to try to use AppleScript, this may indeed enhance convenience for the end user. But the potential for fouling this up is considerable: after I rename my "Report" as "Old report" and build a new "Report," I'd like throw "Report" at printer to send the new report, not the old one. To get real scary, throw "Books" at IRS had better send the right set of books... I also admit that I'm uncomfortable about alias files generally -- they feel a bit too much like trapdoors, often trapdoors to oblivion. So at this point, I agree with Tim that fileIDs don't help much, and misuse could be "interesting." At the risk of starting a "yeah, but can you do THIS?" war, does anyone have a real application for these things? =Ned Horvath=
usenet@cps3xx.UUCP (Usenet file owner) (09/05/89)
In article <951@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: > [ Paraphrased from Tim Maroney ] >1. What good are these things? What can "reference by fileID" >accomplish that "reference by pathname" cannot? It lets me move things around without changing the aliases. Basically, it allows the programmer (and perhaps the user, if this is integrated into the Finder) to change the hierarchical directory structure into a network structure. Pathnames don't do this, because if I change the name of a file (which conceptually does NOT change the object--this is important) then my aliases all break. Same if I move it into a different directory. For those who insist on comparing aliases to symbolic links: SYMBOLIC LINKS ARE MISERABLE IF YOU MOVE FILES AROUND! (Sorry for yelling, but I've spent a lot of time fighting this problem...) >2. More importantly: what impact do these "programmer only" names have >on the end-user's mental model? If they're tied into the Finder, they allow a more flexible directory structure. It's kinda like HyperCard--you can have arbitrary links. Sometimes this can be confusing; if carefully used, it's nice. For instance... Suppose I have a directory called "Current work" which is stuff I'm currently working on. I decide it's time to update my book database, so I put an alias for it in the "Current work" directory to remind myself to do it. Later in the day, I feel like cleaning up my HyperCard files, and move them around a bit. My new alias is still working, even though I renamed and moved my "Book" file to be called "Book database". I have to leave this now because my system is going to reboot, but you get the idea I hope.... P.S. Will only files be "aliasable", or directories as well? +----------------------------------+-------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | University of Wisconsin--Madison | rang@cpsvax.cps.msu.edu | +----------------------------------+-------------------------+
amanda@intercon.uu.net (Amanda Walker) (09/06/89)
I may just be staid and boring, but I don't see the point of all of the people that say how File IDs will make it so much easier to "move files around." How many people rearrange their disks a lot (beyond the first 2 weeks right after purchase, anyway)? The closest thing I can think of that I do is occasionally rearrange my directory hierarchy now and then. I mean, I can construct scenarios where I would move things around a lot, but I find it hard to imagine actually doing so in normal day-to-day life. Aliases make it a little easier to imagine, but still... How many people actually feel that File IDs will solve a problem they have with using their Macintosh? I don't mean to flame--I'm genuinely curious, although I'm interested in more concrete answers than "it would just be cool, that's all" :-)... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "The trouble with doing something right the first time is that nobody appreciates how difficult it was" --Walt West
usenet@cps3xx.UUCP (Usenet file owner) (09/06/89)
In article <1436@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >I may just be staid and boring, but I don't see the point of all of the >people that say how File IDs will make it so much easier to "move files >around." How many people rearrange their disks a lot (beyond the first >2 weeks right after purchase, anyway)? The closest thing I can think of >that I do is occasionally rearrange my directory hierarchy now and then. I don't rearrange my disk a lot, but I do move individual files around quite a bit based on usage. For instance, when I'm using my terminal emulator a lot, it tends to get moved closer up toward the top of the hierarchy (normally it sits far down within 3 folders). If I'm doing much work with a story I'm writing, that folder pops up a bit (I would move the particular chapter up, but there isn't a good place to put it, except on the Desktop which makes my top level messy). >I mean, I can construct scenarios where I would move things around a lot, >but I find it hard to imagine actually doing so in normal day-to-day life. >Aliases make it a little easier to imagine, but still... It depends on usage patterns, I guess. I could live with a method that let the Finder keep track of things on the Desktop better, even. I wouldn't mind putting things on the Desktop (though it might get cluttered) if they would stay in their home folders (one of my pet peeves about HFS vs. MFS)! Also, it's nice to keep some applications together with their data files, but have the application somewhere more easily accessible. I would love to be able to have a folder which contained, say, aliases for my 8 most-frequently-used applications, and another with aliases for utility programs. I can do that right now, but their data files don't stick around, and neither do documentation files (or help files, configuration files, etc.). That's what I'd use aliases for: so I don't have to open 4 levels of folders to get at an application, even though that's where I want to put the application *and its files* (if there aren't any other files there's no problem with the current method). Comments? Suggestions? Anything? +----------------------------------+-------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | University of Wisconsin--Madison | rang@cpsvax.cps.msu.edu | +----------------------------------+-------------------------+
leipold@eplrx7.UUCP (leipold) (09/06/89)
In article <4468@cps3xx.UUCP> rang@frith.egr.msu.edu (Anton Rang) writes: > I would love to be able to have a folder which contained, say, >aliases for my 8 most-frequently-used applications, and another with >aliases for utility programs. ... That's what I'd use aliases for: >so I don't have to open 4 levels of folders to get at an application, >even though that's where I want to put the application *and its files*. Sounds like the Un*x 'PATH' variable to me... How about some user-specified environment variables on the Mac (like 'WordPATH', 'PaintPATH', etc.)? -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) --
kent@sunfs3.camex.uucp (Kent Borg) (09/07/89)
In article <1436@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >I may just be staid and boring, but I don't see the point of all of the >people that say how File IDs will make it so much easier to "move files >around." How many people rearrange their disks a lot (beyond the first >2 weeks right after purchase, anyway)? The closest thing I can think of \--------------^--------------------/ [don't under estimate the importance of those first two weeks--or two minutes] >that I do is occasionally rearrange my directory hierarchy now and then. ... >How many people actually feel that File IDs will solve a problem they >have with using their Macintosh? I don't mean to flame--I'm genuinely >curious, although I'm interested in more concrete answers than "it >would just be cool, that's all" :-)... I don't think they solve many current problems, but I do think they prevent future problems with aliases. I know from my own use of computers, and recently Bill Steinberg's Launch application, that aliases will have value. What I don't know is whether they will be worth the confusion they will add to the Macintosh user interface. That is a different question. Let's, for the moment, ignore that question and assume aliases are a good idea. In the Macintosh, the user is King. So, what will aliases look like to the `average' user? The prototypical "Mom" is often wheeled in at this point, and my mother got a Macintosh Plus at Christmas so... "Well, Mom, an alias is a little like a magic window on another file or application on your disk." "Oh, like a copy." "Yes, but there is still only one copy of the file, there is just more than one way to get at it." "Oh... Why would I want that?" And here the question of the value of aliases reappears, but what of the explanation? With the alias being the volume name and file ID, the simple explanation above fits. It is the file which has an alias. If, instead, the alias is implemented with a path it is no longer the file alone which has an alias, it is the file in a particular location on a particular path. My mother a week later: "I've been using these aliases a little, but they don't always work. They sometimes ask me where the file is, even when I haven't moved it. Why do they keep forgetting?" "The aliases point to the file--but only in that one place. If you move the file you will have to change all its aliases--or if you change the name of any of the folder along the path--" "What `Path'?" "Um, it's a technical term. If you have a folder inside a folder and change the name of the outside folder, the alias will no longer be able to find what is in the the inner folder." "Why not? Never mind... So if I use aliases I won't be able to rearrange my windows?" "No, you can move things inside a folder, just not between folders, and you can't change any of the names." "*Any* names?" "No, any of the names `above' the aliased file." "`Above'? I'm not sure I understand, but it sure seems dumb. Why can't it just refer to the file whereever it is? It saw me move it or change some important name someplace, it should know where the file is, why ask me?" "Umm, It wasn't paying attention. If computers were simple, people like wouldn't make as much money..." Using file IDs to implement aliases means that the *files* have aliases. Using path names means that the *paths* have the aliases. What do Macintosh users currently deal with, files or paths? Which will be clearest for users? Files of course, the things which have icons. Why should users have any reason to have to worry about paths? Don't think of file IDs as private, competing names, think of them as serial numbers. Whether you call your car Bertha or Betty has nothing to do with which car it is, and which car it is can be unambigiously referred to by its vehical identification number. A file ID says which file it is, independent of the name, and the file ID has different purposes from those of a name. Apple already avoided paths once in its design of the Macintosh (search paths for finding applications), and it was a good idea, it made the Macintosh much easier to use. Once again, I think it is important to keep paths out of it and not force the user to worry about the concept of a path at all. It is confusing and unnecessary. >"The trouble with doing something right the first time is that nobody > appreciates how difficult it was" --Walt West Yup. -- Kent Borg "You know me, bright ideas kent@lloyd.uucp just pop into my head!" or -Mrs Lovett ...!husc6!lloyd!kent (from Stephen Sondheim's "Sweeny Todd")
pem@cadnetix.COM (Paul Meyer) (09/07/89)
In article <4468@cps3xx.UUCP> rang@frith.egr.msu.edu (Anton Rang) writes: >In article <1436@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >>around." How many people rearrange their disks a lot (beyond the first >>2 weeks right after purchase, anyway)? The closest thing I can think of >>that I do is occasionally rearrange my directory hierarchy now and then. > > I don't rearrange my disk a lot, but I do move individual files >around quite a bit based on usage. For instance[...] > > It depends on usage patterns, I guess. I could live with a method >that let the Finder keep track of things on the Desktop better, even. >I wouldn't mind putting things on the Desktop (though it might get >cluttered) if they would stay in their home folders (one of my pet >peeves about HFS vs. MFS)! Also, it's nice to keep some applications >together with their data files, but have the application somewhere >more easily accessible. > I would love to be able to have a folder which contained, say, >aliases for my 8 most-frequently-used applications, and another with >aliases for utility programs. I can do that right now, but their data >files don't stick around, and neither do documentation files (or help >files, configuration files, etc.). That's what I'd use aliases for: >so I don't have to open 4 levels of folders to get at an application, >even though that's where I want to put the application *and its files* >(if there aren't any other files there's no problem with the current >method). Anton has expressed the reasons why the FileID aliasing scheme answers a lot of my (user-level) prayers for UNIX-like links in the Mac file system. As many other people have seemed to indicate, though, there is also a need for an equivalent to BSD _symbolic_ links, which just store a relative or absolute path to the file. For example, I'm working on a project that can be described as several applications that use a common datafile format. I've hacked up a messy editor for the files and got it working, and now I'm working on various other parts of the system. I have separate Think C (Thinc?) projects for each application, referencing some common include files, with separate resource files and lots of separate source files for each one. Without symbolic aliases, I can take advantage of a nifty TC feature to put the common include files one place and put ifdefs controlling them in a subfolder for the project, but all the other source code and stuff has to coexist in the folder. If I bury something in a subfolder, again TC comes to my rescue and searches for it. Now, because TC is so nifty I am not pulling my teeth out over this problem, but if I used word processors as heavily as I do my development system I think I would be. (Of course, in MPW I could put the right stuff in the Makefile, but MPW is not exactly the bastion of a user interface for "the rest of us", and most non-development applications have no equivalent capacity.) It would be nice to have a system feature to make this work for any application. To end my ramblings, I guess the one place I would really need symbolic links is kind of made moot by the problem already being solved another way, but I have my own question: would a symbolic link structure be useful to any of the people who are bemoaning the "hard" link equivalent in System 7.0? Paul Meyer pem@cadnetix.COM Daisy/Cadnetix Inc. (DAZIX) {uunet,boulder}!cadnetix!pem 5775 Flatirons Pkwy. GEnie P.MEYER Boulder, CO 80301 (303)444-8075x277
sbb@esquire.UUCP (Stephen B. Baumgarten) (09/07/89)
In article <1436@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >I may just be staid and boring, but I don't see the point of all of the >people that say how File IDs will make it so much easier to "move files >around." How many people rearrange their disks a lot (beyond the first >2 weeks right after purchase, anyway)? The closest thing I can think of >that I do is occasionally rearrange my directory hierarchy now and then. At first I felt as you do, Amanda, but then I thought about problems that hierarchical paths present when Apple implements their new publish/subscribe method of inter-application communication (IAC). Since applications will be storing references to files, you really don't want to have your word processor draw your company's logo on your letter using a live link to the file ``hd:drawings:picts:logo''; rather, it should be looking for FILEID=1823 or whatever. Chances are I'm going to move that ``logo'' file at some point, yet I don't want my word processor to choke in 6 months because as far as it can see, the file no longer exists. >I mean, I can construct scenarios where I would move things around a lot, >but I find it hard to imagine actually doing so in normal day-to-day life. >Aliases make it a little easier to imagine, but still... I agree, but I know that I reorganize things at least 3 or 4 times a year (as I get new applications, etc.). Mostly these aren't major reorganizations, but it only takes one application to pronounce one file ``missing'' to get a non-technical user utterly confused. Given that under Apple's publish/subscribe IAC scheme applications are going to be storing references to many external documents in their own documents, I don't see how anything other than unique file IDs could be used and still allow the user freedom to move and rename files. Or have I just missed something obvious here? -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." sbb@esquire.dpw.com | cmcl2!esquire!sbb | - David Letterman
jk3t+@andrew.cmu.edu (Jonathan King) (09/07/89)
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
blm@6sigma.UUCP (Brian Matthews) (09/08/89)
In article <1399@esquire.UUCP> sbb@esquire.dpw.com writes: |In article <1436@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: |>I may just be staid and boring, but I don't see the point of all of the |>people that say how File IDs will make it so much easier to "move files |>around." |At first I felt as you do, Amanda, but then I thought about problems |that hierarchical paths present when Apple implements their new |publish/subscribe method of inter-application communication (IAC). |Since applications will be storing references to files, you really |don't want to have your word processor draw your company's logo on |your letter using a live link to the file ``hd:drawings:picts:logo''; |rather, it should be looking for FILEID=1823 or whatever. Chances are |I'm going to move that ``logo'' file at some point, yet I don't want |my word processor to choke in 6 months because as far as it can see, |the file no longer exists. What happens if Joe Random User decides to change logos, or tweek the existing one. He wants to save the old logo, so in the Finder he moves it to logo.old. He then goes into Illustrator or whatever, and creates a new file called logo. He then goes into his word processor and prints a letter. No new logo. He goes back to Illustrator, and sure enough, the new logo. It even prints nicely. Back to the word processor. No new logo. After a sufficient bit of screaming and hair pulling, Joe might realize that every file has two names. One that is shown in the Finder and is real easy to change, and one that isn't shown and can't be changed. Of course Joe might never realize this, and throw his Mac out the window instead. -- Brian L. Matthews blm@6sigma.UUCP Six Sigma CASE, Inc. +1 206 854 6578 PO Box 40316, Bellevue, WA 98004
shebanow@Apple.COM (Andrew Shebanow) (09/08/89)
Before we let this whole file ID thing get out of hand, I'd like to point out a few things: First of all, the documents that describe file IDs that were given out at the Developer Conference were PRELIMINARY. The design has changed quite a bit since then, so any assumptions made based on those documents could be hazardous to your software. We made it very clear to people at the conference that these materials were being distributed to give developers an idea of the direction we were heading in, and not as the newest volume of Inside Mac. So please, lets try and keep a clear head about this stuff, OK? Secondly, the file ID capability doesn't have to be implemented on every volume. There is a higher level facility, the Alias Manager, which will work transparently across all volumes, including those that don't support file IDs. Alias Manager aliases will have all of the functionality of UNIX soft links, and then some. Please don't ask me for details of the Alias Manager or of file IDs. I don't have any newer documentation, and I wouldn't be able to give it out if I did have it. All you can do is wait for the System 7.0 seeds to arrive. Have fun, Andrew Shebanow Amway Representative, MacDTS Apple Computer, Inc.
amanda@intercon.uu.net (Amanda Walker) (09/08/89)
In article <4072@internal.Apple.COM>, shebanow@Apple.COM (Andrew Shebanow) writes: > Before we let this whole file ID thing get out of hand, I'd like to > point out a few things: > > First of all, the documents that describe file IDs that were given > out at the Developer Conference were PRELIMINARY. The design has > changed quite a bit since then, so any assumptions made based > on those documents could be hazardous to your software. Quite true. My objection is mostly philosophical, and I'm even moderating on that a little bit these days. My basic problem was (and still is) having two (or more) access paths to a file, which can be decoupled from each other. I think this is a bad idea as it stood in the preliminary docs. The underlying issue seems to be that it can be very useful to refer to a file's name and it's contents separately. I still think that this has the potential for all sorts of confusion, but I do admit that it can reduce other kinds of confusion... -- Amanda Walker amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "Nihil est ab omni parte beatum." Tr.: "Nothing is an unmixed blessing." --Horace