Forum: Public Review
References: Rose & Yen public review comment #3
Section 19.1.2, "Pathnames as Filenames"
Category: CLARIFICATION, CHANGE
Edit history: 26-Dec-1992, Version 1 by Loosemore
Status: Item (4) removed; remainder of proposal passed 7-0-2,
The specification provides no reliable way for application programs
to detect and recover from file system errors.
The specific situation raised by the referenced public review comment
was failure of OPEN due to the file being read- or write-protected.
However, there are numerous other situations which may also cause OPEN
(as well as other file-related operations, such as PROBE-FILE,
DIRECTORY, and the like) to fail. These include things like directory
components in the pathname that don't really name directories, or
invalid symbolic links. The dictionary pages for most of these
functions say nothing about what happens in the event the file system
is unable to perform the request.
To complicate matters further, there is also a related class of purely
syntactic pathname errors that were the subject of proposal
PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE, which was incorporated
into draft 12.24 as the second paragraph on page 19-2. Nothing is
said in that section either about whether an error must be
signaled, or the type of such an error. The problem description of
that issue left open the possibility that an implementation might
attempt to make `friendly' corrections to syntactically invalid
pathnames -- e.g., truncating names that are too long -- instead of
signaling an error, but the discussion in the draft does not mention
this explicitly. Since one of the provisions of the proposal was to
"warn users clearly about this known source of program portability
problems", it seems some further clarification of how pathname syntax
errors may be handled is in order.
If that weren't enough, some functions specify that the type of error
signalled when a wildcard pathname is provided is TYPE-ERROR, and
others specify that it is of type FILE-ERROR.
(1) Add to the "Exceptional Situations" section of the dictionary
pages for DIRECTORY, PROBE-FILE, TRUENAME, FILE-AUTHOR, FILE-WRITE-DATE,
OPEN, WITH-OPEN-FILE, COMPILE-FILE, LOAD, ED, and DRIBBLE a statement
that an error of type FILE-ERROR is signaled if the file system cannot
perform the requested operation. (The entries for RENAME-FILE and
DELETE-FILE already include similar language.)
If the proposals to restore the pathname argument to REQUIRE and/or
to add the ENSURE-DIRECTORIES-EXIST function pass, add the same
statement to the dictionary entries for these functions.
(2) Rewrite and expand the second paragraph on page 19-2 to read:
The mapping of the pathname components into the concepts peculiar to
each file system is implementation-defined. There exist conceivable
pathnames for which there is no mapping to a syntactically valid
filename in a particular implementation. An implementation may use
various strategies in an attempt to find a mapping; for example, an
implementation may quietly truncate filenames that exceed length
limitations imposed by the underlying file system, or ignore certain
pathname components for which the file system provides no support. If
such a mapping cannot be found, an error of type FILE-ERROR is
The time at which this mapping and associated error signaling occurs
is implementation-dependent. Specifically, it may occur at the time
the pathname is constructed; when coercing a pathname to a namestring;
or when an attempt is made to open or otherwise access the file
designated by the pathname.
At the editor's discretion, also note this in the "Exceptional
Situations" section of the dictionary pages for the affected
functions. These functions are: PATHNAME, MAKE-PATHNAME,
PATHNAME-HOST and friends, LOGICAL-PATHNAME-TRANSLATIONS,
NAMESTRING and friends, PARSE-NAMESTRING, WILD-PATHNAME-P,
PATHNAME-MATCH-P, TRANSLATE-LOGICAL-PATHNAME, TRANSLATE-PATHNAME,
MERGE-PATHNAMES, COMPILE-FILE-PATHNAME, and all of the functions
mentioned in item (1) of the proposal.
(3) Change the dictionary entries for PROBE-FILE, TRUENAME,
FILE-AUTHOR, and FILE-WRITE-DATE to say that the type of error
signalled when a wildcard pathname is provided is FILE-ERROR rather
than TYPE-ERROR. (The entries for RENAME-FILE, DELETE-FILE, OPEN,
WITH-OPEN-FILE, COMPILE-FILE, and LOAD already specify a type of
Also, add a statement that an error of type FILE-ERROR might be
signalled if the pathname argument is wild to the dictionary entries
for COMPILE-FILE-PATHNAME, ED, DRIBBLE, and (if the appropriate
proposals pass) REQUIRE and ENSURE-DIRECTORIES-EXIST.
(4) Deprecate the function PROBE-FILE.
Providing detailed information about when and what type of errors
might be signalled allows users to include condition handlers at
relevant places in their programs which can take appropriate action
to report and/or recover from the error.
It's clear that FILE-ERROR is the correct condition type for the
kinds of errors covered by item (1) of the proposal. It could be
argued that the errors covered by items (2) and (3) ought to be of
some other condition type, but since in some cases these errors might
be reported by the file system in the same way as the errors from
item (1), it may be difficult to distinguish them in practice.
The rationale for deprecating PROBE-FILE is that the general approach
of trying to check whether a file operation is going to succeed ahead
of time is not the right way to handle file system access problems.
Also, its functionality can readily be duplicated by OPEN and/or
Cost to implementors:
Cost to users:
Cost of non-adoption:
Continuing confusion about how to handle file system errors.
I suppose having the standard made more explicit on this issue is an
improvement, even if it makes it longer.
There are a large number of functions affected, but the changes are
fairly mechanical in nature.
A completely different proposal, PROBE-FILE:ADD-DIRECTION-KEYWORD,
was originally suggested by Rose & Yen in their public review comment.
The gist of that proposal was to modify PROBE-FILE so it could be used
to check whether the user had privilege to subsequently OPEN a file.
The public review committee concluded this was an unsatisfactory
approach, not only because it didn't allow for detection of other
kinds of file access problems, but also because it could be defeated
by changes to the file system in between the check and the attempted
access. In subsequent e-mail discussion, the commentors have agreed
to withdrawing that proposal in favor of the one presented here.
Loosemore admits to being skeptical about the rationale for deprecating
PROBE-FILE (in particular, because doing so would seem to indicate
that there are no valid uses of PROBE-FILE at all), but the original
commentors requested us to consider it.