PROBE-FILE

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Mon, 08 Apr 85 15:02:22 EST
    From: greek@DEC-HUDSON

    Rob's proposal makes sense.  A few comments:
    ...
    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).

It is precisely because of this need to return a multitude of kinds of 
information that the Lisp Machine has gone away from having more functions 
to do this kind of investigation and toward using errors to convey this
information. In the Lisp Machine's not-really-new-any-more "new error system",
failure is flavorized so that a lot of kinds of information can be extracted
depending on what the caller needs to know. This also has the important
advantage that users who don't realize they need to detect odd situations
will have their code stopped cold in its tracks rather than having it 
stumble on and notice a problem only later.

For example, in Lisp Machine lisp, if you want to know if the failure was 
due to device doesn't exist, you can take the error object and do:
 (TYPEP error-object 'FS:DEVICE-NOT-FOUND)
or if you want to know if a directory was not found, you do:
 (TYPEP error-object 'FS:DIRECTORY-NOT-FOUND)
Or if you want more general information you can do:
 (TYPEP error-object 'FS:FILE-LOOKUP-ERROR)
which will find both FS:DEVICE-NOT-FOUND errors and FS:DIRECTORY-NOT-FOUND
errors. This allows error signallers to be quite exact about the error
that occurred (by mixing in as many error types as are known to be relevant)
and still have a fair chance that the handler will do something reasonable
(by allowing it to look for more specific condition types than are actually
signal.

If you compare this to what you're asking for PROBE-FILE, you quickly
realize that there is no obvious way to stop a huge explosion of functions
named things like:
 (PROBE-FILE-RETURNING-NIL-FOR-BAD-PATHNAME ...)
 (PROBE-FILE-RETURNING-NIL-FOR-BAD-DEVICE-BUT-ERRING-ON-OTHER-PATHNAMES ...)
 ...
or a huge explosion of keywords as in:
 (PROBE-FILE ... :ALLOW-ERROR-IF '(:BAD-DEVICE :BAD-DIRECTORY))
or a huge explosion of return values as in:
 (PROBE-FILE pathname) => pathname-or-NIL,
		          device-not-found-p,
			  device-not-valid-p,
			  directory-not-found-p,
			  ...
or a huge explosion of keywords in return values such as
 (PROBE-FILE pathname) => pathname-or-NIL, reason-keyword (one of 
			   :DEVICE-NOT-FOUND, :DIRECTORY-NOT-AVAILABLE,...)
etc. The problem with these situations is that you are then locked into a
bottomless pit of having to make non-general extensions to the language
every time a new situation comes up. 

In the Lisp Machine case, the definition of PROBEF is fairly simple. It 
returns a pathname if the probe code succeeds and the file was there, 
NIL if the probe code succeeds but no file was there, and errs if the probe
code encounters a problem. How those problems may occur is something
which users know is device dependent and subject to change as new devices
are added or devices change their behavior.  The really nice point is that
flavors were designed to accomodate both the process of change and some 
sense of ambiguity in terms of what the error type is ("Is it a string error
or a file error? hmm. Guess i'll make a new flavor file-string-error so
that people watching for either situation can handle it.") 

So I really think this is something to be relegated to error handling.
Although there's been little discussion on the error handling mailing list,
I did get what I think is a fairly workable proposal out before discussion
died down, so don't worry that we're just talking pipe dreams here.

That's about all I have to say on the subject for now. Over the past
several years using the LispM file system, I've been extremely pleased
with how little I had to think about the target file system because of
the nice abstractions upon which it's based. So my proxy basically goes
to Moon for any further discussion on this subject. Just wanted to say
something supportive since on sheer volume of mail it might have 
appeared he wasn't being believed.