Probe-File and proposed extension.

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Mon, 8 Apr 85 14:33 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 8 Apr 1985  10:23 EST
	From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	Query:
	    Should Probe-File never signal an error, even if it is given a
	namestring which is malformed?

No, it should signal lots of errors.

	Proposal:
	    There needs to be some way to determine whether a file name is
	legal for output.  I brought this issue up once before on this mailing
	list, but I think the discussion died.  I am bringing it up again
	because we need something of the sort in Spice Lisp, so I am going to
	implement it.  My proposed solution is the following:  Probe-File
	should take a direction argument, which defaults to :input.  The
	semantics of Probe-File would be to return the pathname which would be
	used if the file was opened in that direction, and to return NIL if
	the open would fail.  

    What's wrong with calling OPEN and handling the error when it fails?  Since
    I don't understand the desired application, I don't know whether my question
    makes sense.

Answered below.

    "Common Lisp does not have a standard way to handle errors" is not an acceptable
    answer.  It should get one.

    Date: Mon, 8 Apr 1985  14:55 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	There are circumstances where being able to validate a filename as
    potentially writable without actually writing that file would be
    useful.  

    The specific problem I want to solve involves the the "Visit File"
    command in Hemlock.  If you visit a file that exists, you read the
    file, and the pathname associated with the buffer becomes the truename
    of the file; no problem there.  The question is what do you do if
    Probe-File of the filename is false?  Does this mean that the file
    simply doesn't exist, or does it mean that the filename is somehow
    broken?  An example of a broken filename would be one with a
    nonexistant directory or device.

	If the filename is broken it would be useful to be able to
    tell the user this when he visits the file, rather than getting some
    error when he tries to save it.  

I see.  In our implementation, the ambiguous phrase (actually lifted
from the old Lisp Machine manual) "if there is no file named" in the
documentation of PROBE-FILE is interpreted to mean that only a
file-not-found error returns NIL; any other error, such as
directory-not-found, host-not-up, name-too-long, etc. is signalled in
the normal way.  Thus PROBE-FILE serves as a test for whether you'll be
able to write the file, assuming you have access to write, the host is
still up when you try to write, the disk hasn't filled up by then, etc.
Another way of saying this is that PROBE-FILE returns NIL without
signalling an error if it would be possible for the file to exist at
some future time (well, this is still ambiguous, after all someone could
create a directory, rename a device, buy a new computer, or whatever).

I think this means that our PROBE-FILE does everything your Visit File
command needs.

But I see that others could interpret the Common Lisp manual differently.
I suppose the manual has to be ambiguous because anything more specific
might be unimplementable on some file system!  I think it would be better
for you to fix your PROBE-FILE (to signal errors other than file-not-found)
than to change its arguments to make it optional to do so.

				     It is also useful to be able to get
    the name of the file that you expect to be created, since then you can
    set the buffer pathname to that, rather than leaving it a relative
    pathname until the file is actually created.

Agreed.  Our understanding is that MERGE-PATHNAMES is how relative
pathnames get expanded.  The manual doesn't say anything about relative
pathnames, but I don't see how anything but MERGE-PATHNAMES could expand
them, since they have to be relative to some default.  But maybe you
mean something different by "relative pathnames" than I; after all, the
manual doesn't define the term.  I mean pathnames with relative directory
names, which start at some default directory in the tree of directories,
rather than starting at the root.  In Unix, all pathnames that don't start
with a slash.

    Date: Mon, 08 Apr 85 15:02:22 EST
    From: greek@DEC-HUDSON
    ....
    3.  PROBE-FILE needs to tell me more.  I want to know if I can't get
	at the file because:
	  a)  the file spec is bad.
	  b)  the device doesn't exist.
	  c)  the directory doesn't exist.
	  d)  I don't have sufficient access privilege.
	  e)  etc., etc.

    The basic need addressed by Rob is a real one:  Is this file spec good,
    can I get to the file, and what can I do to it (read, write, etc).

Agreed, but see below.

    Although I certainly agree that Common LISP needs an error
    handling facility, I don't want to have to use it to investigate
    whether or not a file exists.  

Why not?

    That's a basic file operation for which we've already attempted to
    account.  Let's fix up the way we do it, not just punt it.

Why is using the error-handling facility considered punting?

    Date: Mon, 8 Apr 1985  15:22 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	A while back when bogosity in the file system chapter was being
    discussed on this list, Moon proposed that :direction :probe be
    flushed, and everyone seemed to agree.

I still think so.  It should exist only as an internal implementation
detail of PROBE-FILE in some implementations.

    Date: Mon, 8 Apr 1985  15:33 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	The issue of how to get back more information about what is wrong
    with a file was where we got bogged down before.  I think that error
    systems are the called for when you start to consider that sort of
    issue.  Any enumeration of all the things that can go wrong with
    writing a file will also probably be hopelessly implementation
    dependent.  

I agree.  Look at Greek's list above, for example, especially item (e).

		Unless you can come up with a simple, highly esthetic
    proposal, I think we should stick with NIL for failure.

	I suppose we could return an error-message string as a second
    value, but anything along those lines seems like a sort of half-way
    measure to me.

I don't think a string is what is going to be wanted in many cases, since
it is not program-understandable.