Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.unix.wizards
Subject: Re: lockf and the SVID, (Was "Re: Wanted: lockf system call source")
Message-ID: <1362@ttrdc.UUCP>
Date: Wed, 3-Dec-86 00:50:31 EST
Article-I.D.: ttrdc.1362
Posted: Wed Dec  3 00:50:31 1986
Date-Received: Wed, 3-Dec-86 07:09:16 EST
References: <5413@brl-smoke.ARPA> <2264@sdcsvax.UCSD.EDU> <1860@utah-gr.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 23

In article <1860@utah-gr.UUCP>, thomas@utah-gr.UUCP writes:
>
>Why would you require a file open for write to set a write lock?
>Consider the following scenario:
>	fd = open( "/etc/passwd", 0 );	/* this is ok */
>	lock_for_write( fd );		/* Not so good, eh? */
>	sleep( 1000000000 );		/* Now try to change your password */

I guess not!

However, this kind of situation (one program shutting off another's access to
a file because the first program is reading it) can happen in the supposedly
modern operating system VMS.  This has some rather bizarre consequences.

I can see no harm from ADVISORY locks on a file open for read only, however.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy