[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue FILE-OPEN-ERROR Writeup

Forum:		Public Review

Issue: FILE-OPEN-ERROR

References: Rose & Yen public review comment #3

OPEN

PROBE-FILE

Section 19.1.2, "Pathnames as Filenames"

Issue PATHNAME-SYNTAX-ERROR-TIME

Issue PATHNAME-WILD

Category: CLARIFICATION, CHANGE

Edit history: 26-Dec-1992, Version 1 by Loosemore

Status: Item (4) removed; remainder of proposal passed 7-0-2,

March 1993

Problem description:

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.

Proposal (FILE-OPEN-ERROR:SIGNAL-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

signaled.

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

FILE-ERROR.)

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.

Rationale:

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

TRUENAME.

Current practice:

Unknown.

Cost to implementors:

Probably small.

Cost to users:

Probably small.

Cost of non-adoption:

Continuing confusion about how to handle file system errors.

Aesthetics:

I suppose having the standard made more explicit on this issue is an

improvement, even if it makes it longer.

Editorial impact:

There are a large number of functions affected, but the changes are

fairly mechanical in nature.

Discussion:

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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.