Kenyon_F_Karl@cup.portal.com (02/16/91)
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
wayne@csri.toronto.edu (Wayne Hayes) (02/16/91)
Well, some Unixes support *voluntary* file locking, that is, the OS will tell you if a file is locked only if you ask, but it's not enforced. Also, the first process has to explicitly lock the file, and the second process has to explicitly ask if the file is locked. Regardless of whether the file is locked, the second (any any other) process(es) may open the file and do with it as they please. This can usually be construed as a feature, and is *very* useful under many circumstances. It is in fact quite rare that two processes will access the same file for writing at the same time without each other's knowledge. It requires that either the file is writable by more than one user ID, or that one person is silly enough to start two different programs that write to the same file when they're not supposed to. The only time I have ever encountered the former is with an older Unix system that had the /usr/spool/mail/gripes file world-writable so you could put gripes there. Occasionally someone would put a gripe there via mail (as they should), but later want to edit the message. This is why the file was world-writable. Then under the extraordinary circumstance that this very same urge befalls two people at the same time, the first poor fellow to save his changes looses those changes when the second guy saves *his* changes. This happened only once that I know of. Anyway, it's very useful to be able to have one process write while another reads, for instance when you have a log file being created in the background and you want to read the log file with "tail -f" (which BTW doesn't yet work in Minix, but I'll be posting some diffs for tail in the near future to support this.) -- "Dad, what should I be when I grow up?" "Honest." -- Robert M. Pirsig, _Zen and the Art of Motorcycle Maintenence_. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (02/17/91)
>Well, some Unixes support *voluntary* file locking, that is, the OS will >tell you if a file is locked only if you ask, but it's not enforced. >Also, the first process has to explicitly lock the file, and the second >process has to explicitly ask if the file is locked. Regardless of >whether the file is locked, the second (any any other) process(es) may >open the file and do with it as they please. Actually some Unices have *mandatory* locking, but this was not included in POSIX. If people are interested look up fcntl() in the POSIX standard. The rationale they give for not including mandatory locks was the varied methods used on different systems and the difficulty of implementing it on systems that support memory mapped IO... Bill Bogstad P.S. to original starter of this thread (whose address I lost) Everything in my private e-mail to you was correct for some version of UNIX, (just not POSIX). :-) Just think of this as another example of UNIX assumming that the user/programmer knows what they are doing.
ronald@robobar.co.uk (Ronald S H Khoo) (02/17/91)
wayne@csri.toronto.edu (Wayne Hayes) writes: > Well, some Unixes support *voluntary* file locking, that is, the OS will > tell you if a file is locked only if you ask, but it's not enforced. Xenix and reasonably current releases of System V DO support mandatory (ie it *is* enforced if you ask for it to be) file locking. Perhaps you are thinking of BSD ? > Also, the first process has to explicitly lock the file, and the second > process has to explicitly ask if the file is locked. Not if mandatory file locking has been requested. The exact behaviour depends on the implementation, but typically reads/write requests will block until the lock has been released, and creat() may fail with EAGAIN. > [ advisory locking can be ] > construed as a feature, and is *very* useful under many circumstances. This is, of course true. But as you note, mailboxes should be locked with mandatory locking where available. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
ast@cs.vu.nl (Andy Tanenbaum) (02/17/91)
In article <1991Feb16.013731.18087@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: >Well, some Unixes support *voluntary* file locking, that is, the OS will >tell you if a file is locked only if you ask, but it's not enforced. V1.6.11 already has the full P1003.1 file locking implemented. Andy Tanenbaum (ast@cs.vu.nl)
kirkenda@eecs.cs.pdx.edu (Steve Kirkendall) (02/19/91)
In article <39313@cup.portal.com> Kenyon_F_Karl@cup.portal.com writes: >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. The file in /usr/tmp is more than just a lock file. It is used to contain a copy of the file being edited, with extra space inserted to make editing faster. Whenever Elvis dies for any reason (system crash, elvis bug, lost carrier, power failure, etc.) the "virec" program can be used to recover the changed text that is stored in that temporary file. The fact that this file acts as a lock file is really just an unfortunate consequense of the method Elvis uses for filename generation. I plan to remove that limitation soon. ------------------------------------------------------------------------------- Steve Kirkendall kirkenda@cs.pdx.edu Grad student at Portland State U.