Re: Questions about OPEN

[Charles Hedrick <HEDRICK@RUTGERS.ARPA>]

Maybe I didn't make it clear why I sent the message.  I thought somebody
was suggesting that we should try to separate functions that take stream
arguments from those that take filenames (pathnames).  In this case I
would expect that read and write would take streams, and rename and
delete would take filenames.  If nobody proposed this, then my answer is
genuinely devoid of usefulness.  I was arguing that it is useful to
continue to have rename-file and delete-file take either streams or
filenames.  I assume I don't have to convince you that they should
take filenames.  Sometimes we just want to rename a file, and if it
isn't open, we don't want to bother having to open it, rename it, and
close.  The argument is (or at least I was imagining that it is) about
whether rename and delete should be legal on streams.  I claim that
they should, for the very case that concerns you:  I may not know the
name of the file that I want to rename.  Thus it is useful to have an
operation that requests changing its name to something new, without
reference to any name that it may happen to have now.  In case you don't
know the name of a file until you close it, you have at least two choices:
  - close it, remember the name it got assigned (I trust you can find
	out the name of a file when you close it?), rename it, and if
	the semantics of rename-file are deemed to require this, reopen
	it.
  - if your O.S. lets you not specify the name until you close it,
	don't do anything to the file -- just change the name you
	are going to give it when it finally gets closed.
I certainly don't have any solution to the truename problem.  I
understand that there is a genuine problem with that function on some
O.S.'s.  I was trying to point out that allowing operations on open
streams can in some cases make the situation a bit better because we
don't ever need to know the old name of the file.

I have thought about your question as to when the JFN should be
released.  I intended it to get released when you closed the stream. At
the moment rename-file implies a close in our implementation.  This may
be a bug.  (Would someone from the gang of 5 like to comment?) But that
is not relevant to this question.  I was trying to preserve the ability
to do certain operations on a stream while it is still open, not say
they should never get closed.

By the way, a suggestion for doing truename on systems where you don't
know the name until close:  If you have some way of making a file
invisible (e.g. by setting file protection so that no one can see it),
you could close it when it is initially opened, make it invisible, and
then open it for append access.  This is roughly what Tops-20 does
internally.  (Tops-20 has the same problem that this scheme would have:
if the system crashes while you are creating a file, you have this
partially-created file lying around which you may need to use unusual
methods to get rid of.)
-------