[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
- Subject: :IF-EXISTS :SUPERSEDE
- From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
- Date: Tue, 6 Dec 83 15:54 EST
- Cc: CWH%SCRC-TENEX@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI.ARPA, Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA, ROM%SCRC-TENEX@MIT-MC.ARPA, file-protocol%SCRC-TENEX@MIT-MC.ARPA, jwalker%SCRC-TENEX@MIT-MC.ARPA
- In-reply-to: The message of 6 Dec 83 10:30-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>
Date: Tuesday, 6 December 1983, 10:30-EST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Date: Monday, 5 December 1983, 23:12-EST
From: David A. Moon <Moon at SCRC-TENEX>
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.
Could you detail the sequence of operations? The above is not sufficiently
clear. When do you open the second file? Under what name?
Sure. Here's the sequence of operations, translated from Midas to English:
Do a GTJFN to look up the file name specified. The options specified
are one of the following cases:
- direction is not output => tell the system to look up an existing
version, complain if no file is found, and never create a new file.
- direction is output (no bidirectional support yet);
if append, overwrite, or truncate is set and create is not
=> tell the system to barf if no file is found and to look
up an existing version if newest is specified.
- if any of supersede, append, overwrite, truncate, rename, rename-and-delete,
or if-exists-error is set
=> tell the system to look up an existing version if the version is
newest, rather than creating a new version, and tell it to barf if
an existing file is found.
- otherwise => tell it to create a new file if the version is newest
and to barf if an existing file is found.
The result of this GTJFN is # cases:
(1) A file is found/created with no error => use it
(2) An error other than file-already-exists, or any error if
if-exists-error was specified => return error to user
(3) File-already-exists error
=> GTJFN again, telling the system to look up the existing file.
[An error here is just signalled to the user, and means someone
changed something, e.g. deleted the existing file out from under
you. Probably should start over rather than erring out.]
Now if append, overwrite, or truncate is set, use that file.
Otherwise save that file, along with a flag saying whether
rename, rename-and-delete, or supersede was specified. Open
the file for input with the "restricted" option so that no
one else can mess with it; if this fails return an error;
Tops-20 doesn't allow you to supersede a file that someone
is using, unlike some other systems that will hold onto the
file until all users of it close.
Now open a temporary file in the same directory and use it.
At non-abort close time, rename the temporary file on top of
the other file, superseding it. (For rename/rename-and-delete,
the other file is renamed out of the way first).
Hopefully I haven't perpetrated too many typographical errors in the
above. I don't think the Tops-20 strangeness of having separate system calls
to get a handle on a file and to open a file is depended on in any