[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-STREAM (Version 5)
- To: Ram@C.CS.CMU.EDU
- Subject: Issue: PATHNAME-STREAM (Version 5)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 23 Oct 87 15:00 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <RAM.12344817269.BABYL@>
Date: Fri, 23 Oct 1987 13:46 EDT
Date: Friday, 23 October 1987 12:52-EDT
From: Masinter.pa at Xerox.COM
[...] I enhanced the discussion section, and added a reference to
p. 417 "the name returned represents the name used to open the
file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
Sounds like XCL is wrong here, although the whole file system interface
chapter is so fuzzy that it's hard to say for sure that anything is wrong.
I think that this should be read as a warning that PATHNAME on an open
stream doesn't necessarily return the truename of the file ultimately
written, or even necessarily the truename of any file that ever
existed or will exist.
Agreed. It seems clear that PATHNAME on an open stream returns something
that resembles the pathname argument that was given when the stream was
opened. I say "resembles" because of defaulting of unspecified fields
in the original argument.
If this is read as a strict requirement, then it is pretty clearly
wrong, since presumably if you do a RENAME-FILE on the stream, you want
PATHNAME of that stream to return the new name, rather than the name
it was originally opened with.
Probably. That's what we do.
If you are trying to clean up the rot with streams as pathnames, you
should carefully look over section 23.3 pp 423-425, as many of these
functions are suggested to do something semantically different with a
stream argument as with PATHNAME of that stream argument.
I think I said that too, in my original comments on this issue.
For example, the claim that PROBE-FILE should never return NIL when
called on an open stream is pretty clearly wrong. In some
implementations, the file doesn't exist at all until the stream is
closed. I believe the semantics of PROBE-FILE on a stream should in
fact be the same as PROBE-FILE on PATHNAME of that stream, but maybe
we shouldn't guarantee that.
Calling TRUENAME on a stream open for output is also highly suspect,
since it is possible that the ultimate name of the file cannot be
predicted, even disregarding possible renamings. (consider version
In our implementation, TRUENAME just calls PROBE-FILE and then
complains if the result is NIL. This means that TRUENAME on an open
stream can signal an error. If this violates someone's TRUENAME
invariants, then we should firm up the definition of TRUENAME
It's very difficult to come up with crisp semantics that are implementable
on all file systems. I think for PROBE-FILE and TRUENAME on an open
stream, we can either allow returning NIL / signalling an error, or we
can say that if the file doesn't exist yet (on output) / any more (on input),
these functions are supposed to return their best estimate of what the
file name will be / used to be, which might involve a version number of
:newest. I think the latter is what Symbolics does, since it tends to
make more things work on more file systems.