Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no writeup)

[masinter.pa@Xerox.COM]

I had this (and others) message filed under that issue name. The
disposition was "wait until there is an signal proposal." Now that there is
a signal proposal, I am pretty sure that it doesn't address this issue. 

I'd like a volunteer to write this up as an issue. (Is DLW a candidate?)

There is additional discussion on this topic, that I will forward. 


     ----- Begin Forwarded Messages -----

Date: Mon, 15 Dec 86 07:54 EST
 From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: FILE-WRITE-DATE, FILE-AUTHOR
To: common-lisp@SU-AI.ARPA
cc: toto@YUKON.SCRC.Symbolics.COM, cal@THINK.COM
Message-ID: <861215075436.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

FILE-WRITE-DATE and FILE-AUTHOR are both vague on what
happens if the file does not exist.  The text says:

    @I[file] can be a filename or a stream that is open to a file.
    This returns the time at which the file was created or last
    written as an integer in universal time format (see section 25.4.1),
    or NIL if this cannot be determined.

(FILE-AUTHOR is similar).

My reading of this is that the phrase "if this cannot be determined"
means "determined by looking at the file", not "determined for any
reason".  I think the intent here is to cover such situations as
an operating system which doesn't support creation dates, or a
network link which doesn't support inquiring about dates.

Situations like giving the wrong pathname, temporary network failure,
or no access rights should signal an error.

PROBE-FILE and DIRECTORY are also a bit vague on these matters, saying
nothing about what happens when you can't inquire about files due to
network failure or no access rights.

I also think that if the directory doesn't exist, you should get an
error, not just return NIL, but this would need to wait until we have an
error system, or the incompatibility would be too large.

USER-HOMEDIR-PATHNAME says "if it is impossible to determine this
information, then NIL is returned instead of a pathname;".  It's
not clear whether this means "is impossible right now due to a
system error" or "is impossible to inquire of that host".  Returning
NIL due to a transient condition is both uninformative to the user
and may lead to suprising behaviour, like reading in the wrong files
or refusing to do something.

The :IF-DOES-NOT-EXIST NIL option to OPEN does not say what it
does about things like network errors, etc.

A lot of people seem to assume that if CLtL doesn't say anything
about errors, then a function may not signal any errors, even if
something goes wrong.  Hopefully the new error system standard will
address a lot of these issues, but some clarification (or at least
agreement on the intent) would help now.


     ----- End Forwarded Messages -----

Date: Tue, 26 May 87 14:40 EDT
 From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: file-write-date for non-existant files
To: kmp@ALDERAAN.SCRC.Symbolics.COM, Masinter.PA
cc: dlw@ALDERAAN.SCRC.Symbolics.COM, moon@ALDERAAN.SCRC.Symbolics.COM


Recently I tried porting a CL program from the Prime to the Symbolics
implementation.  I found that the program depended on the function
file-write-date, when given a non-existant file, to return NIL rather
than signalling an error.  CLtL, with its usual nonspecificity, says
that file-write-date should return NIL if the write date "cannot be
determined".  I feel this is not completely clear; does this mean "if
the file system doesn't keep track of write dates for files", or does it
mean "if anything goes wrong whatsoever, including 'the network is down
right now' or 'attempts to compute this file write date happen to
stimulate a bug in multiply'"?

I was wondering if there are any pending cleanup proposals that bear
on this question.  If not, I'd be interested in submitting one.  Thanks.