Text File

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 <jgoerzen@complete.org> 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.