Issue: PATHNAME-STREAM (Version 5)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 23 Oct 1987  13:46 EDT
    From: Ram@C.CS.CMU.EDU

	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
    numbers)

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

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.