220 lines
16 KiB
HTML
220 lines
16 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue FILE-OPEN-ERROR Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss156_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss157.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss158_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss156_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss157.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss158_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue FILE-OPEN-ERROR Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Public Review<P>
|
|
<B>Issue:</B> <A HREF="iss157.htm">FILE-OPEN-ERROR</A><P>
|
|
<B>References:</B> Rose & Yen public review comment #3<P>
|
|
<A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A><P>
|
|
<A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A><P>
|
|
Section 19.1.2, "Pathnames as Filenames"<P>
|
|
Issue <A HREF="iss265.htm">PATHNAME-SYNTAX-ERROR-TIME</A><P>
|
|
Issue <A HREF="iss267.htm">PATHNAME-WILD</A><P>
|
|
<B>Category:</B> CLARIFICATION, CHANGE<P>
|
|
<B>Edit history:</B> 26-Dec-1992, Version 1 by Loosemore<P>
|
|
<B>Status:</B> Item (4) removed; remainder of proposal passed 7-0-2,<P>
|
|
March 1993<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
The specification provides no reliable way for application programs<P>
|
|
to detect and recover from file system errors.<P>
|
|
<P>
|
|
The specific situation raised by the referenced public review comment<P>
|
|
was failure of <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> due to the file being read- or write-protected.<P>
|
|
However, there are numerous other situations which may also cause <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A><P>
|
|
(as well as other file-related operations, such as <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A>, and the like) to fail. These include things like directory<P>
|
|
components in the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> that don't really name directories, or<P>
|
|
invalid symbolic links. The dictionary pages for most of these<P>
|
|
functions say nothing about what happens in the event the file system<P>
|
|
is unable to perform the request.<P>
|
|
<P>
|
|
To complicate matters further, there is also a related <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> of purely<P>
|
|
syntactic <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> errors that were the subject of proposal<P>
|
|
<A HREF="iss265.htm">PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE</A>, which was incorporated<P>
|
|
into draft 12.24 as the second paragraph on page 19-2. Nothing is<P>
|
|
said in that section either about whether an error must be<P>
|
|
signaled, or the type of such an error. The problem description of<P>
|
|
that issue left open the possibility that an implementation might<P>
|
|
attempt to make `friendly' corrections to syntactically invalid<P>
|
|
pathnames -- e.g., truncating names that are too long -- instead of<P>
|
|
signaling an error, but the discussion in the draft does not mention<P>
|
|
this explicitly. Since one of the provisions of the proposal was to<P>
|
|
"warn users clearly about this known source of program portability<P>
|
|
problems", it seems some further clarification of how <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> syntax<P>
|
|
errors may be handled is in order.<P>
|
|
<P>
|
|
If that weren't enough, some functions specify that the type of error<P>
|
|
signalled when a wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is provided is <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A>, and<P>
|
|
others specify that it is of type <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (FILE-OPEN-ERROR:SIGNAL-FILE-ERROR):<P>
|
|
</B><P>
|
|
(1) Add to the "Exceptional Situations" section of the dictionary<P>
|
|
pages for <A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A>, <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_tn.htm#truename"><B>TRUENAME</B></A>, <A REL=DEFINITION HREF="../Body/f_file_a.htm#file-author"><B>FILE-AUTHOR</B></A>, <A REL=DEFINITION HREF="../Body/f_file_w.htm#file-write-date"><B>FILE-WRITE-DATE</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A>, <A REL=DEFINITION HREF="../Body/m_w_open.htm#with-open-file"><B>WITH-OPEN-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>, <A REL=DEFINITION HREF="../Body/f_ed.htm#ed"><B>ED</B></A>, and <A REL=DEFINITION HREF="../Body/f_dribbl.htm#dribble"><B>DRIBBLE</B></A> a statement<P>
|
|
that an error of type <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A> is signaled if the file system cannot<P>
|
|
perform the requested operation. (The entries for <A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A> and <P>
|
|
<A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A> already include similar language.)<P>
|
|
<P>
|
|
If the proposals to restore the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> argument to <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> and/or<P>
|
|
to add the <A REL=DEFINITION HREF="../Body/f_ensu_1.htm#ensure-directories-exist"><B>ENSURE-DIRECTORIES-EXIST</B></A> function pass, add the same<P>
|
|
statement to the dictionary entries for these functions.<P>
|
|
<P>
|
|
<P>
|
|
(2) Rewrite and expand the second paragraph on page 19-2 to read:<P>
|
|
<P>
|
|
The mapping of the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components into the concepts peculiar to<P>
|
|
each file system is implementation-defined. There exist conceivable<P>
|
|
pathnames for which there is no mapping to a syntactically valid<P>
|
|
filename in a particular implementation. An implementation may use<P>
|
|
various strategies in an attempt to find a mapping; for example, an<P>
|
|
implementation may quietly truncate filenames that exceed length<P>
|
|
limitations imposed by the underlying file system, or ignore certain<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components for which the file system provides no support. If<P>
|
|
such a mapping cannot be found, an error of type <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A> is<P>
|
|
signaled.<P>
|
|
<P>
|
|
The time at which this mapping and associated error signaling occurs<P>
|
|
is implementation-dependent. Specifically, it may occur at the time<P>
|
|
the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is constructed; when coercing a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> to a namestring;<P>
|
|
or when an attempt is made to open or otherwise access the file <P>
|
|
designated by the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
<P>
|
|
At the editor's discretion, also note this in the "Exceptional <P>
|
|
Situations" section of the dictionary pages for the affected <P>
|
|
functions. These functions are: <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>PATHNAME-HOST</B></A> and friends, <A REL=DEFINITION HREF="../Body/f_logica.htm#logical-pathname-translations"><B>LOGICAL-PATHNAME-TRANSLATIONS</B></A>, <P>
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> and friends, <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A>, <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_mat.htm#pathname-match-p"><B>PATHNAME-MATCH-P</B></A>, <A REL=DEFINITION HREF="../Body/f_tr_log.htm#translate-logical-pathname"><B>TRANSLATE-LOGICAL-PATHNAME</B></A>, <A REL=DEFINITION HREF="../Body/f_tr_pn.htm#translate-pathname"><B>TRANSLATE-PATHNAME</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp__1.htm#compile-file-pathname"><B>COMPILE-FILE-PATHNAME</B></A>, and all of the functions<P>
|
|
mentioned in item (1) of the proposal.<P>
|
|
<P>
|
|
(3) Change the dictionary entries for <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_tn.htm#truename"><B>TRUENAME</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_file_a.htm#file-author"><B>FILE-AUTHOR</B></A>, and <A REL=DEFINITION HREF="../Body/f_file_w.htm#file-write-date"><B>FILE-WRITE-DATE</B></A> to say that the type of error<P>
|
|
signalled when a wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is provided is <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A> rather <P>
|
|
than <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A>. (The entries for <A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/m_w_open.htm#with-open-file"><B>WITH-OPEN-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, and <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> already specify a type of<P>
|
|
<A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A>.)<P>
|
|
<P>
|
|
Also, add a statement that an error of type <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A> might be<P>
|
|
signalled if the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> argument is wild to the dictionary entries <P>
|
|
for <A REL=DEFINITION HREF="../Body/f_cmp__1.htm#compile-file-pathname"><B>COMPILE-FILE-PATHNAME</B></A>, <A REL=DEFINITION HREF="../Body/f_ed.htm#ed"><B>ED</B></A>, <A REL=DEFINITION HREF="../Body/f_dribbl.htm#dribble"><B>DRIBBLE</B></A>, and (if the appropriate<P>
|
|
proposals pass) <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> and <A REL=DEFINITION HREF="../Body/f_ensu_1.htm#ensure-directories-exist"><B>ENSURE-DIRECTORIES-EXIST</B></A>.<P>
|
|
<P>
|
|
(4) Deprecate the function <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Providing detailed information about when and what type of errors<P>
|
|
might be signalled allows users to include condition handlers at<P>
|
|
relevant places in their programs which can take appropriate action<P>
|
|
to report and/or recover from the error.<P>
|
|
<P>
|
|
It's clear that <A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A> is the correct condition type for the<P>
|
|
kinds of errors covered by item (1) of the proposal. It could be<P>
|
|
argued that the errors covered by items (2) and (3) ought to be of<P>
|
|
some other condition type, but since in some cases these errors might<P>
|
|
be reported by the file system in the same way as the errors from <P>
|
|
item (1), it may be difficult to distinguish them in practice.<P>
|
|
<P>
|
|
The rationale for deprecating <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A> is that the general approach<P>
|
|
of trying to check whether a file operation is going to succeed ahead<P>
|
|
of time is not the right way to handle file system access problems.<P>
|
|
Also, its functionality can readily be duplicated by <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> and/or<P>
|
|
<A REL=DEFINITION HREF="../Body/f_tn.htm#truename"><B>TRUENAME</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
Unknown.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Probably small.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Probably small.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
Continuing confusion about how to handle file system errors.<P>
|
|
<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
I suppose having the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> made more explicit on this issue is an<P>
|
|
improvement, even if it makes it longer.<P>
|
|
<P>
|
|
<P>
|
|
<B>Editorial impact:<P>
|
|
</B><P>
|
|
There are a large number of functions affected, but the changes are<P>
|
|
fairly mechanical in nature.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
A completely different proposal, PROBE-FILE:ADD-DIRECTION-KEYWORD,<P>
|
|
was originally suggested by Rose & Yen in their public review comment.<P>
|
|
The gist of that proposal was to modify <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A> so it could be used<P>
|
|
to check whether the user had privilege to subsequently <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> a file.<P>
|
|
The public review committee concluded this was an unsatisfactory<P>
|
|
approach, not only because it didn't allow for detection of other<P>
|
|
kinds of file access problems, but also because it could be defeated<P>
|
|
by changes to the file system in between the check and the attempted<P>
|
|
access. In subsequent e-mail discussion, the commentors have agreed<P>
|
|
to withdrawing that proposal in favor of the one presented here.<P>
|
|
<P>
|
|
Loosemore admits to being skeptical about the rationale for deprecating<P>
|
|
<A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A> (in particular, because doing so would seem to indicate<P>
|
|
that there are no valid uses of <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A> at all), but the original<P>
|
|
commentors requested us to consider it.<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|