Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) (05/30/91)
You make the call. I had a file, call it Foo, in folder Bar. I made an alias of Foo called Foo.alias. Then I wanted to back up Foo, so I dragged Foo from Bar into a folder called Bar.Backup. Yup, forgot to hold down the option key... damn! So now Foo is in Bar.Backup. OK, no problem. I option-drag Foo back into Bar. So now: original Foo is in Bar.Backup, copy of Foo (also called Foo) is in Bar. OK, time to panic... almost forgot about the alias!! I get info on Foo.alias, ask it to find the original file, and it pulls up... the copy of Foo in folder Bar! Well, I guess this was what I wanted (it corrected my mistake :-), but I don't think this is right. What do you all think?
lbaum@bcsaic.UUCP (Larry Baum) (05/30/91)
In article <1991May29.202307.3024@dartvax.dartmouth.edu> Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) writes:
: You make the call.
:
: I had a file, call it Foo, in folder Bar. I made an alias of Foo
: called Foo.alias. Then I wanted to back up Foo, so I dragged Foo from
: Bar into a folder called Bar.Backup. Yup, forgot to hold down the
: option key... damn! So now Foo is in Bar.Backup. OK, no problem. I
: option-drag Foo back into Bar. So now: original Foo is in Bar.Backup,
: copy of Foo (also called Foo) is in Bar.
:
: OK, time to panic... almost forgot about the alias!! I get info on
: Foo.alias, ask it to find the original file, and it pulls up... the
: copy of Foo in folder Bar!
:
: Well, I guess this was what I wanted (it corrected my mistake :-), but
: I don't think this is right. What do you all think?
This behavior seems ok, but the real issue is what happens if
you do this:
create Foo in folder Bar
create Foo.alias
move (not copy) Foo into folder Bar.Backup
Now where does Foo.alias point? If it still points to Bar,
that would be bad.
Since I haven't upgraded to Sys7 yet, I ask the question.
--
Larry Baum
Advanced Technology Center
Boeing Computer Services uucp: uw-beaver!bcsaic!lbaum
(206) 865-3365 internet: lbaum@atc.boeing.com francis@wolfman.cis.ohio-state.edu (RD Francis) (05/31/91)
In article <48263@bcsaic.UUCP> lbaum@bcsaic.UUCP (Larry Baum) writes: In article <1991May29.202307.3024@dartvax.dartmouth.edu> Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) writes: : You make the call. : : I had a file, call it Foo, in folder Bar. I made an alias of Foo : called Foo.alias. Then I wanted to back up Foo, so I dragged Foo from : Bar into a folder called Bar.Backup. Yup, forgot to hold down the : option key... damn! So now Foo is in Bar.Backup. OK, no problem. I : option-drag Foo back into Bar. So now: original Foo is in Bar.Backup, : copy of Foo (also called Foo) is in Bar. : : Well, I guess this was what I wanted (it corrected my mistake :-), but : I don't think this is right. What do you all think? This behavior seems ok, but the real issue is what happens if you do this: create Foo in folder Bar create Foo.alias move (not copy) Foo into folder Bar.Backup Actually, append: copy (not move) Foo into folder Bar to your list of activities, and that's what the original poster did. I would expect create foo in folder Bar create foo.alias foo.alias points to Bar:foo move foo to folder Bar.Backup foo.alias points to Bar.Backup:foo copy foo to folder Bar foo.alias points to Bar.Backup:foo to be the sequence of actions, and the results of those actions. -- R David Francis francis@cis.ohio-state.edu
philip@pescadero.Stanford.EDU (Philip Machanick) (06/01/91)
In article <48263@bcsaic.UUCP>, lbaum@bcsaic.UUCP (Larry Baum) writes: |> In article <1991May29.202307.3024@dartvax.dartmouth.edu> Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) writes: |> : I had a file, call it Foo, in folder Bar. I made an alias of Foo |> : called Foo.alias. Then I wanted to back up Foo, so I dragged Foo from |> : Bar into a folder called Bar.Backup. Yup, forgot to hold down the |> : option key... damn! So now Foo is in Bar.Backup. OK, no problem. I |> : option-drag Foo back into Bar. So now: original Foo is in Bar.Backup, |> : copy of Foo (also called Foo) is in Bar. |> : |> : OK, time to panic... almost forgot about the alias!! I get info on |> : Foo.alias, ask it to find the original file, and it pulls up... the |> : copy of Foo in folder Bar! |> : |> : Well, I guess this was what I wanted (it corrected my mistake :-), but |> : I don't think this is right. What do you all think? It doesn't seem right to me. Try this: delete the copy in Bar. Now, Get Info can't find it. Next: move the copy from Bar.Backup to Bar and try it again. Now it does find it - even if the "backup" copy has been changed. It seems the name is good enough. Can anyone explain the semantics of this and why it isn't going to land someone in trouble? |> This behavior seems ok, but the real issue is what happens if |> you do this: |> |> create Foo in folder Bar |> create Foo.alias |> move (not copy) Foo into folder Bar.Backup |> |> Now where does Foo.alias point? If it still points to Bar, |> that would be bad. In this case, it does what you'd expect - the alias "moves". -- Philip Machanick philip@pescadero.stanford.edu
rmh@apple.com (Rick Holzgrafe) (06/01/91)
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 <volumeName,folderID,fileName>. 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."
jeffe@eniac.seas.upenn.edu (george) (06/01/91)
: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. : ... : :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 are the details of alias resolution 'semantics' explained in the system 7 manuals. Experience with past Apple manuals leads me to assume that there will be no explination, but the new maunals are reported to be 'much better'. If this sort of thing is there I may just go out and spent some money on them. -- -george george@mech.seas.upenn.edu
philip@pescadero.Stanford.EDU (Philip Machanick) (06/01/91)
In article <43994@netnews.upenn.edu>, jeffe@eniac.seas.upenn.edu (george) writes: |> are the details of alias resolution 'semantics' explained in the |> system 7 manuals. |> |> Experience with past Apple manuals leads me to assume that there will be |> no explination, but the new maunals are reported to be 'much better'. |> |> If this sort of thing is there I may just go out and spent some money on them. I couldn't find such an explanation. On the other hand, many of the questions that used to take up so much net bandwidth are now answered, like how to suppress printing a startup page and how to download PostScript. A pity the Contents page numbering is screwed up from Chapter 8 onwards. (Not a good ad for the DTP software listed at the end.) -- Philip Machanick philip@pescadero.stanford.edu
lsr@Apple.COM (Larry Rosenstein) (06/04/91)
In article <13808@goofy.Apple.COM> rmh@apple.com (Rick Holzgrafe) writes: > >The canonical "address" of a file is a triplet of ><volumeName,folderID,fileName>. This is the method of choice (here I'm >guessing! I'm not a guru on this) because folderIDs are unique (forever) According to IM 6, when you create an alias to a file, the system creates a file ID for the file. The file ID will let the alias track the file anywhere on the same volume even if it has changed name. (The file ID is a unique ID for files, in the same way that the dir ID is a unique ID for directories.) The alias does store the information about the name of the target (probably by volume name, dir ID, and filename). If you do Get Info on an alias, it will show the path to the target, based on the information stored in the alias. If you click Find Original, then the alias is resolved and that information may need to be updated. >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 This is a backup strategy, I believe. If you make an alias to a file named foo, rename foo to bar, and make a new file called foo, then the alias should still refer to the original file (now named bar). >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 There is in System 7. File IDs are unique within a volume and seem to track a file regardless of whether it is moved or renamed. It may not work with certain kinds of backup and restores, in the same way the dir IDs may not survive a backup/restore. For replacing files during a save (which is the best technique), there's a special call to swap the file ID for the old and new files. This lets you preserve the file ID even though the actual file is a new one. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
lsr@Apple.COM (Larry Rosenstein) (06/04/91)
In article <1991May31.170319.1179@neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >In article <48263@bcsaic.UUCP>, lbaum@bcsaic.UUCP (Larry Baum) writes: >|> In article <1991May29.202307.3024@dartvax.dartmouth.edu> Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) writes: [steps involving foos, bars, and aliases] I couldn't find the original article by Eric, but I tried the steps quoted in the follow ups and it didn't behave the same way. The alias always found the same physical file, regardless of where it was. >to Bar and try it again. Now it does find it - even if the "backup" >copy has been changed. It seems the name is good enough. Can anyone >explain the semantics of this and why it isn't going to land someone I think if the original file has been deleted, the next step is to look for something in the original place with the same name. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
pmbergla@watcgl.waterloo.edu (Per Bergland) (06/04/91)
In article <13848@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <13808@goofy.Apple.COM> rmh@apple.com (Rick Holzgrafe) writes: >> >>The canonical "address" of a file is a triplet of >><volumeName,folderID,fileName>. This is the method of choice (here I'm >>guessing! I'm not a guru on this) because folderIDs are unique (forever) > >According to IM 6, when you create an alias to a file, the system creates a >file ID for the file. The file ID will let the alias track the file >anywhere on the same volume even if it has changed name. (The file ID is a >unique ID for files, in the same way that the dir ID is a unique ID for >directories.) > >The alias does store the information about the name of the target (probably >by volume name, dir ID, and filename). If you do Get Info on an alias, it >will show the path to the target, based on the information stored in the >alias. If you click Find Original, then the alias is resolved and that >information may need to be updated. But what I don't like is the following: If you have an alias to the cool game you just wrote and compiled, delete the application, recompile it, and then do a Get Info on the alias, this will show the correct path and name that you want (e.g. HD40SC:Cool:.Non-Debug Files:HejSvejs), but pressing Find Original gives you the prompt "Can't find file"(or something like that). OK, OK, its only my opinion... -Per
keith@Apple.COM (Keith Rollin) (06/04/91)
In article <13848@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > >According to IM 6, when you create an alias to a file, the system creates a >file ID for the file. The file ID will let the alias track the file >anywhere on the same volume even if it has changed name. (The file ID is a >unique ID for files, in the same way that the dir ID is a unique ID for >directories.) IMO, Inside Mac VI is slightly misleading on this score. Files have always had unique file IDs associated with them (see the field at byte offset 20 in the picture on page 172 of IM IV). However, there was no quick way to look up a file's catalog entry based on that ID. With 7.0, HFS now has the ability to create special hidden catalog entries (called "file thread records") that allow this quick lookup. When IM refers to being able to create IDs for files, it is really referring to these new records. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo