IF-EXISTS :SUPERSEDE

["David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>]

    Date: Monday, 5 December 1983, 11:25-EST
    From: Bernard S. Greenberg <BSG at SCRC-TENEX>
    Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
    
    We are having a little dispute here about the intended semantics of
    :IF-EXISTS :SUPERSEDE on output, when the file version of the pathname
    to be opened is :NEWEST.  The manual is not specific on what this means.

It (Excelsior edition) says "This differs from :NEW-VERSION in that
:SUPERSEDE creates a new file with the same name as the old one".  That
seems quite specific to me.  If you write a.b.newest in :IF-EXISTS
:SUPERSEDE mode, you create a new file with the same version number as
the newest existing version of a.b, replacing (superseding) that
existing file.

It might be valuable for the manual to contain a note such as "if the
version component of the pathname is :NEWEST, then one of two rules
for developing a specific version number is used.  If the value of
:DIRECTION is :OUTPUT or :IO and the value of :IF-EXISTS is :NEW-VERSION,
then a version number one higher than the highest existing version is
used.  In all other cases, the highest existing version is used."

    Argument #1:
      Imagine a program that took user input for a file name, and wrote
      out to that file.  (Can't argue with that, right?).  Suppose further
      that this program did not like the CL default of :error, and wanted
      you to be able to write out to a.b.3 if that's what you said.
      So it might open its file with :IF-EXISTS :SUPERSEDE.  Well, suppose
      you said a.b.newest to it?  You CERTAINLY don't want it looking up
      what the latest version is and superseding it!  You want it to create
      a new version.
    
This is a good point; a program with such a user interface needs to check
pathname-version of its pathname to decide what :IF-EXISTS option to use,
since we failed to provide one that implements that behavior.

    Argument #2:
      Given the primitives available to the file server in versionated
      operating systems, it is impossible to implement this as proposed
      without a window between determining the version number and opening
      it for superseding.
    
This argument is false.  The Tops-20/Tenex Chaosnet file server has
no problem doing this without windows.  During the time between opening
and closing, the old file is in an "open for reading" state that
prevents anyone else from superseding it or renaming it.  Presumably other
versionated operating systems may have comparable primitives.

It seems to me that what we must do is quite clear and there are no
choices to be made.