#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.