Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!Kenyon_F_Karl
From: Kenyon_F_Karl@cup.portal.com
Newsgroups: comp.os.minix
Subject: File locking in MINIX and UNIX
Message-ID: <39313@cup.portal.com>
Date: 16 Feb 91 03:58:55 GMT
Organization: The Portal System (TM)
Lines: 84

TO: Andrew S. Tanenbaum
EMS: Internet
MBX: ast@cs.vu.nl
CC: Ken Kleiner - BUCEC
EMS: FAX
MBX: Phone: 508-649-6926
CC: Brian 'Doc' O'Neill
EMS: Internet
MBX: oneill@ulowell.edu
Subject: File locking in MINIX 1.5 and UNIX systems in general

The following is being posted to USENET newsgroup 'comp.os.minix':

MINIX 1.5 hung while running 'elvis'(vi editor), presumably due to some 
keyboard problem that I will have to figure out 'someday'. In my ignorance, 
I rebooted the machine, and even ran the program 'fsck'. When I started to 
run 'elvis' again, the program returned the following error message (quoted 
from /usr/src/commands/elvis/tmp.c and vi.h):

# define TMPNAME        "/usr/tmp/elvt%04x%04x" /* temp file */


        /* make a name for the tmp file */
        sprintf(tmpname, TMPNAME, statb.st_ino, statb.st_dev);

        /* make sure nobody else is editing the same file */
        if (access(tmpname, 0) == 0)
        {
                FAIL("\"%s\" is busy", filename);
        }


Thus, my immediate problem is that rebooting the system while 'elvis' was 
still running left a temporary file in /usr/tmp. When 'elvis' found the 
file after the reboot, it thought that the file was still being edited. 
Running the command 'rm /usr/tmp/*' as 'superuser' removed the temp file. 

I am wondering whether I should add the following lines to the shell script 
'/etc/rc' as a more permanent solution to this and similar problems. Kerni-
gan and Pike's book 'The Unix Programming Environment suggests on pages 64-
65 that these directories are "cleaned up automatically when the system 
starts":

     rm /tmp/*
     rm /usr/tmp/*

However, as I study the UNIX operating system, I have the growing suspicion 
that UNIX is somehow missing the notion of 'file locks' and 'record locks'. 
Thus, on page 203 of K & P's book, I find the statement: "Its quite legal 
for several processes to be accessing the same file at the same time; 
indeed, one process can be writing while another is reading. If this isn't 
what you wanted, it can be disconcerting, but it's sometimes useful."

As 'refugee' from the Honeywell (now Bull) GCOS 8 operating system, I feel 
that this 'feature' to be much more of a problem than K & P suggests!

In the absence of a provision in the operating system, I suspect that each 
programmer that feels the need for some kind of 'lock', codes his own par-
ticular scheme. Thus, if the code for ELVIS is an example, these various 
schemes are so inconsistant with each other as to sharply reduce the value 
of these 'locks'. Thus, if 'elvis' uses one scheme, and another editor 
program uses another, then two copies of 'elvis' can't edit the same pro-
gram, but the two different editors would never know that they were trying 
to edit the same file!

I would like to think that both 'elvis' and the K & P book are both totally 
outdated, and that both MINIX 1.5 and modern versions of UNIX have this 
problem as well controlled as MS-DOS 3.3 (for networking), if not better. 
If so, then I need to know what the 'better answer' is so that I can under-
stand it. I also hope that a more experienced programmer will assume the 
task of fixing the 'elvis' code in an appropriate manner. 

If MINIX itself is out of date as compared to other UNIX systems, then I 
need to know for the times that I get to work on a 'real' system!

If however, this problem remains as one of the 'dirty little secrets' of 
UNIX systems, then I hope that one of the experts will confirm my suspicion 
with a 'stock file' from his collection!

=======================================================================
Kenyon F. Karl
P.O. Box 451, N. Andover, MA 01845
Internet: 1771813@mcimail.com