Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!att!cbnewsk!ech
From: ech@cbnewsk.ATT.COM (ned.horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 & Aliases
Message-ID: <951@cbnewsk.ATT.COM>
Date: 4 Sep 89 16:00:17 GMT
References: <1430@intercon.UUCP>
Organization: AT&T Bell Laboratories
Lines: 66

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=