Aucb.548 fa.editor-p utcsrgv!utzoo!decvax!ucbvax!C70:editor-people Sun Feb 28 11:11:05 1982 Concurrent File Access >From ARK@SU-AI Sun Feb 28 11:07:39 1982 [ Editor's note: the following message, though somewhat specific to Twenex Emacs, raises issues of human interface that are of general interest. What do members of EDITOR-PEOPLE think the most convenient strategy is for avoiding concurrent-access problems? /jqj ] [ITS and Twenex] EMACS has the problem that two people, unbeknownst to each other, can be updating a file concurrently. If both of them try to save their changes, the second one will get the message that the file has changed. This second person has the option of overwriting the first writer's changes or of saving his own changes elsewhere. This is the same as the classical concurrent database access problem. The classic database solution is to introduce locking. I propose the following semantics. These new functions be created: 1. Attempt to write lock a file name. The lock request fails of the file name is locked by by another fork or job or if the file has been changed since it has been read. Status is returned to indicate whether the file name was successfully locked (or who has it if not). This only locks out other attempts to write lock the file name, but does not affect the file system. That is, the file may still be read by other programs. 2. Release a write lock on a file name. The write lock is released if it is owned. Status is returned to indicate whether the lock had been owned. Again, this does not affect the file system. 3. Inquire on the lock status of a file name. Returns the status message that would be returned by function "1--obtain a write lock". 4. Read and write lock a file. Same as "1--obtain a write lock" followed by an exclusive open of the file. This affects the file system. The write lock is released if the exclusive open fails. User functions: A user specifies whether a file is to be read only or updated as well when the user visits a file (e.g., different visit commands are used for each). [Uses operation "3--lock inquiry".] User attempts to update a buffer for the first time (that is, sets the "*" update flag) if the file was read in "update mode". Attempt to write lock the file name. [Uses operation "1".] User saves file. Different commands are used to indicate that this is the final change (release lock, operation "2") or a checkpoint (no change to lock status). User exits or visits a new file in "paranoid" mode. Ask user whether buffers with changes should be saved and whether locked buffers should be unlocked (operation "2"). It would be nice if a series of kills followed by a yank that result in an unchanged buffer cause reset of the "buffer changed" flag. (No need to release a lock, though.) User needs to repair a file and wants to make sure that no one else can look at it or change it. User explicitly issues command to invoke operation "4" after visiting the file. All of these would be new functions that could be mapped onto existing keyboard commands if specified by a particular individual's EMACS.INIT. Thus, it could easily be "upward compatible". Comments and ideas are solicited. Feel free to disseminate this message. Offers of help are most welcome. Arthur ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen 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.