Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!dartvax!earleh
From: earleh@dartvax.UUCP (Earle R. Horton)
Newsgroups: comp.sys.mac
Subject: Re: obtaining the full pathname of a file
Message-ID: <6519@dartvax.UUCP>
Date: Mon, 22-Jun-87 15:29:31 EDT
Article-I.D.: dartvax.6519
Posted: Mon Jun 22 15:29:31 1987
Date-Received: Thu, 25-Jun-87 04:07:14 EDT
References: <1345@batcomputer.tn.cornell.edu> <1007@apple.UUCP> <204@drilex.UUCP> <665@unicus.UUCP>
Organization: Negative Entropy Research and Development Society
Lines: 86
Keywords: pathnames
Summary: no

In article <665@unicus.UUCP>, rae@unicus.UUCP (Clith de T'nir a.k.a. 
        Reid Ellis) writes:
> In article <6462@dartvax.UUCP> earleh@dartvax.UUCP writes:
> |
> | ... Byte the bullet, programmers!  Use PBOpen, PBRead, PBWrite, and
> | the entire ensemble of IN ROM Macintosh file handling routines ...
> | ... you don't have to 
> | obtain the pathname of the file, and you don't have to worry about what
> | happens to your file connection when a disk gets ejected.  Of course,
> | this reduces "portability" but who are we kidding here?
> 
> Um, doesn't this ignore applications where a path is read from a text
> file? [along the lines of a C compiler's "#include <a:long:path>"]  What
> then?  Make the user memorize vRefNums of his folders? :-)

No, it does not.  A full pathname, if it is valid, will OVERRIDE an
explicit volume specification.  (IM, volume IV, File Manager chapter.)
If I were writing a C compiler, and wanted to handle this sort of
thing, this is exactly what I would have the program do:  

     a)  Set up a parameter block for dealing with the file
     b)  Put a zero in the ioVRefNum field
     c)  Put the pointer to the full pathname in the ioNamePtr field
     d)  Fill in ioCompletion, ioVersNum, ioMisc, ioPermssn as 
         appropriate
     e)  Call PBOpen to open the sucker.

Here is the main point:  At no point in this process does my program
have any knowledge of the format of the pathname.  I do not manipulate
the pathname, and I do not attempt to construct the full pathname if I
do not have it.  If the user obtains a file for me from one of the
Standard File Package routines, then the correct thing to do is, in
step b), just put in the vRefNum obtained from SFGetFile or whatever.
If the USER gives me a pathname, then I use it, as is.  Most programs
do not need to know the full pathname of a file, they just need a
RELIABLE means of gaining access to the file.  Using full pathnames on
the Mac is not a reliable means of obtaining access to a file, which
is why it should only be used in cases like Reid's example, above,
where it is absolutely necessary.

The information obtained from the Standard File Package routines is
sufficient to locate a file correctly on any Macintosh.  I do not see
why anyone would wish to translate this information into a format
which is NOT capable of always locating a file correctly.  This is
exactly what you do when you attempt to construct a full pathname to a
file.  This approach may be justified for some applications, but for
the enormous majority of applications that are to be used by ordinary
humans, it introduces the possibility of a run time error which is
simply not acceptable:

     a)  User finds a file name for program using SFPutFile, for
         purposes of saving whatever your program saves.
     b)  Program uses information in SFReply to fabricate a fully
         qualified pathname
     c)  Program does "fopen(pathname,"w");"
     d)  Macintosh knows of another online volume with the same name
         and with the same folder name as the one the user picked from 
         SFPutFile.  The pathname of this folder is identical to the 
         pathname of the folder the User wishes to use to save his
         current work in, with one exception:  It contains the only
         machine-readable copy of the User's PhD. thesis.  By unlucky
         coincidence, the two base file names are identical.
     e)  Macintosh says "I want the other disk."
     f)  User inserts other disk, not suspecting for a moment that he
         is dealing with a dog-meat program.
     g)  Current work is written over User's PhD. thesis.  Screams
         are heard.  A phone call is made to a powerful lawyer's 
	 office.
     h)  "By mistake" you have destroyed a valuable document, and 
         replaced it with something that was supposed to be placed
	 elsewhere.

Let us analyze the above scenario for a moment.  The programmer has been
too lazy to learn the correct way to access a file on the Macintosh.
Instead, he has chosen to use a method that is suited to more to UNIX,
VMS, and MS-DOS systems.  Results were not as expected.  The lazy 
programmer has made the Macintosh look bad, all because he failed to 
detect the difference between a Macintosh and another machine.  I 
leave you with a question:

Can you, members of the jury, think of this as an "honest mistake"?

-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************