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.