Two PROBE-FILE questions

[Jon White <JLW@SU-AI.ARPA>]

In-reply-to: your Msg of 10-Apr-85 14:56 EST

I think you've elucidated, in the second paragraph, the main difficulty
of a non-opening probe-file.  True, one of these problems isn't unique to
probe-for-output -- that of asynchronous change in th file system by some
other process -- but that doesn't lessen the importance.  The second one
(that I was thinking of) is simply the problem of TRUENAME -- unless you
actually open-for-output, then there's a high probability that you can't
find exactly th fully-qualified pathname that the file system would have
returned.  Version numbers is one of the problems; following links may be
another; and finaly (for me, at least) there is the confusion as to whether
the result of a direction-output call is a "file name" or merely a very
hypothetical pathname -- e.g., "this pathname is NOT a file, but if you
had called open instead of probe-file, then this would have been the name
of the file so opened".

Say, Rob, do you get the same sense that I do that something went astray
with this discussion?  In my note of 9-Apr-85, I thought I was arguing
the case for using OPEN directly, rather than preceeding it by a call
to PROBE-FILE; this led to the suggestion to continue the development
of "signals"  *** in order to field the file-not-found error from OPEN ***
But it looks like the discussion centered around fielding error signals
from probe-file.  foo.

If I wasn't clear about my bias before, let me state it now; I don't see
much use for direction-output for probe-file.  Let probe-file remain a
simple function, such as DZG wants, with an informational nature, and
let us discourage users from imagining it to be some kind of file system
semaphore.

-- JonL --