Aucb.566 fa.editor-p utcsrgv!utzoo!decvax!ucbvax!C70:editor-people Mon Mar 1 16:07:21 1982 More on file locking >From Admin.JQJ@SU-SCORE Mon Mar 1 16:01:23 1982 A concensus seems to be developing on E-P that file-level locking to prevent concurrent update while a file is being edited is desirable; the only problems so far advanced have been of implementation. I think I disagree from the human-interface point of view. I often find myself using an editor not to permanently modify a file but only to read or copy parts of it; such uses of a file should NOT require that I have an exclusive lock. Such a lock would in fact be undesirable -- imagine not being able to read the system bulletin board only because someone else was reading it! One solution might be to obtain the lock only when the file is changed, but this is problematical since even reading may be destructive (e.g. when I read a document formatted for lineprinter listing I may well want to refill it to a different right margin). Another (the SUAI approach) is a page-level lock instead of a file-level lock, but that seems only to introduce more problems. I see no easy way for the editor to guess the user's intentions in this regard, and hence no way to hide locking behind file visiting. More generally, one might give the user a choice when visiting a file (perhaps a 3-way choice between read-write mode, read-nowrite mode, and nomodify mode). Such a scheme was tried in ITS Emacs with the distinction between ^X^R, ^X^V and 1FS READ ONLY$; it seems to have been unpopular, since the command distinction has been eliminated. The distinction presents problems if users tend not to know in advance whether they plan to save a changed version of the file, and makes ers tend not to know in advance whether they plan to save a changed version o
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© 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.