Comment 2 for bug 2089439

Although I think it would be reasonable for an implementation's PROBE-FILE to error as Guilherme suggests, I doubt SBCL's user population would enjoy the incompatible change, and the de facto tradition across most implementations has been not to error in PROBE-FILE.

Guilherme: practically speaking, I would propose either implementing a routine with the precise semantics you need using sb-posix or /maybe/ wrapping TRUENAME in something like

```
(defun probe-file* (pathname)
  (handler-bind
      ((file-error (lambda (e)
                     #+sbcl ;; probably elsewhere, too
                     (when
                         ;; This is kind of a gross way to understand what the
                         ;; error is, it seems that no implementation offers
                         ;; any principled interface to its file errors.
                         (search "No such file or directory" (princ-to-string e)
                                 ;; Pure speculative paranoia.
                                 :test #'char-equal)
                       ;; Unix happens not to distinguish whether what's missing
         ;; is the last component in a pathname or any apparent
                       ;; directory. You could do some extra test for the
                       ;; directory here, if that matters to you.
                       (return-from probe-file* nil)))))
    (truename pathname)))
```

But it's really not that practical to rely on any implementation's Chapter 20 operators.

Anyhow, here's how I understand the matter. The Exceptional Situation language in PROBE-FILE (& other Chapter 20 operators) came from the Issue, FILE-OPEN-ERROR:

https://www.lispworks.com/documentation/HyperSpec/Issues/iss157_w.htm

The Issue writeup says the circumstances under consideration include "read- or write-protected [files]... directory components in the pathname that don't really name directories, or invalid symbolic links". This would include Guilherme's scenario (provided directories are files, as is the case on Unix). Its Proposal (1) says the standard was to include a statement that "an error of type FILE-ERROR is signaled if the file system cannot perform the requested operation". (Those words only ended up in the dictionary entries for PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, TRUENAME, and LOAD. The Exceptional Situations for DIRECTORY, ED, DRIBBLE, OPEN, WITH-OPEN-FILE, and COMPILE-FILE are worded somewhat differently.) So ISTM the standard was "supposed to mean" that PROBE-FILE would signal an error in the case Guilherme is considering (and others).

However, even if the standard was intended to mean that, erroring would probably have been an incompatible change for most existing implementation of the time: CLtL1 mandated file-related errors only for RENAME-FILE, DELETE-FILE, OPEN, WITH-OPEN-FILE, and LOAD, and looking at available early implementation sources, it seems that early implementors decided that PROBE-FILE should not error, for whatever reasons. The standardization process aspired to be as backwardly compatible as possible, and so it might have come as a surprise to implementors & users of the time if things changed to start erroring.

Almost all existing implementations today descend from ones that predated ANSI, and sure enough, almost all existing implementations do not signal an error in PROBE-FILE: recentish versions ABCL, Allegro, Clisp, and ECL all return NIL. Of ones I've tested, only CCL appears to be willing to error due to system call failures.

Finally, whatever the standardizers intended, the final language of the standard is arguably ambiguous. In particular, the phrase, "the file system cannot perform the requested operation", could be interpreted to mean "the file system does not offer the features/capabilities to determine whether a file exists or to discover a truename for it". Since a Unix file system has those capabilities, this sense of "cannot" does not apply, and so an error is not indicated. Although we've got evidence that the standard was not supposed to mean this, that evidence and those intentions are not normative on how anybody reads the standard. So we might say the de facto tradition "conforms" to something like this unintended interpretation of the error language in PROBE-FILE. (OTOH, if PROBE-FILE's exceptional language can be interpreted this way, then since FILE-AUTHOR and FILE-WRITE-DATE use the exact same language, arguably all 3 should error or return NIL under the same circumstances. SBCL has FILE-AUTHOR and FILE-WRITE-DATE error, but PROBE-FILE return NIL; CCL has PROBE-FILE error and the other two return NIL; et cetera. IOW, trying to ascribe coherent interpretations of ANSI from implementations' observable behaviors is probably a fool's errand.)