Aucb.676
fa.editor-p
utcsrgv!utzoo!decvax!ucbvax!C70:editor-people
Mon Mar 15 07:26:36 1982
File Locking
>From Ellis.Cohen@CMU-10A Wed Mar 10 22:30:28 1982
I believe that a decent editor should have three kinds of locks available
(all supported by the operating system of course) - read/write, read/only,
and read/current. read/current means that you want to see the current version
of the file even if someone has read/write access to it. read/only will
prevent you from accessing the file if someone else has read/write access.
Usually most people are willing to simply read the latest version of something
so that read/current access suffices. But consider that two files F1 and F2
are not consistent. User A wants to make F2 coform to F1 so read/writes
F2 and read/onlys F1. User B wants to make F1 conform to F2 so read/writes
F1 and read/onlys F2. One or both (forcing both to backoff) won't be able
to get the locks they desire. If they used read/current instead of read/only,
both files would get updated and still not conform!
Also, we should expect to see more editors that support hierarchical
documents. (I'm waiting to see someone discuss what a version of Emacs
would look like that would support nested or linked files/buffers).
Locking then becomes more interesting becuase you get the choice of whether
to lock the whole file or just the piece you are editing. People doing
Database work have considered this question for quite a while - see
"Granularity of Locks in a Shared Data Base" by Gray etal in
the 1975 Conf on Very Large Data Bases.
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
