ricko@sdcsvax.UCSD.EDU (Rick Ord) (08/27/87)
Subject:
MH and flock in Pyramid OSx 4.0
Disclaimer:
I usually don't read comp.mail.mh so please disregard if this has been
posted before. I am cross-posting to comp.sys.pyramid even though Pyramid
does not include MH on their distribution tape.
Description:
I recently put up the new Pyramid OSx 4.0 and had complaints from some users
about MH not working. In particular, simple commands like "inc" returned
errors indicating it could not open and lock their spooled mail file. It
turns out that Pyramid has incorporated the UCB flock and ATT lockf locking
mechanisms into the same vnode (inode) -level record locking routine.
What this all means is that the functionality of ATT lockf is now imposed on
UCB flock.
Under UCB's flock, you could throw an exclusive advisory lock on a file
openned for RDONLY. Under ATT's lockf, you can only throw an exclusive
advisory lock on a file openned for WRONLY or RDWR. As always, a shared lock
can be thrown on a file openned for RDONLY.
So, programs that had used flock to exclusively lock a file RDONLY will not
work - MH is just such a program.
Fix:
Below is a diff of /usr/src/new/mh/zotnet/mts/lock.c
Since this is library routine compiled into the utilities, you will have to
recompile and install from the top level after installing this fix.
Good Luck,
Rick
-----------------------------------------------------------------------------
Rick Ord
UCSD Academic Computing Center
C-010 Rm. 1101-2A (APM)
La Jolla, Ca. 92093 UUCP: ...sdcsvax!ricko
(619) 534-4067 ARPA: ricko@sdcsvax.ucsd.edu
-----------------------------------------------------------------------------
RCS file: RCS/lock.c,v
retrieving revision 1.1
diff -c -r1.1 lock.c
*** /tmp/,RCSt1021950 Thu Aug 27 10:51:01 1987
--- lock.c Thu Aug 27 10:50:37 1987
***************
*** 188,194
for (i = 0; i < 5; i++) {
if ((fd = open (file, access | O_NDELAY)) == NOTOK)
return NOTOK;
! if (flock (fd, LOCK_EX | LOCK_NB) != NOTOK)
return fd;
j = errno;
(void) close (fd);
--- 188,194 -----
for (i = 0; i < 5; i++) {
if ((fd = open (file, access | O_NDELAY)) == NOTOK)
return NOTOK;
! if (flock (fd,((access ? LOCK_EX : LOCK_SH) | LOCK_NB)) != NOTOK)
return fd;
j = errno;
(void) close (fd);hedrick@topaz.rutgers.edu (Charles Hedrick) (08/28/87)
Note also that locks sometimes don't go away in 4.0. Pyramid has just recently found the problem, so it should be available on a PTF shortly. You should SPR your problem to Pyramid. It shouldn't be that hard for them to fix it. While they use common code for flock and flock, there are enough hacks that they can make the semantics differ slightly where necessary. Unless they decide that it would be a security issue to do so...
brian@prism.UUCP (08/28/87)
We have also noticed this with flock():
if you flock with the value LOCK_SH | LOCK_EX, a LOCK_SH is done.
This is in both OSx4.0 and (as far as we can tell) OSx3.1.
Trying this on BSD4.3, LOCK_SH | LOCK_EX locks with LOCK_EX. You may
not notice this until something really bad happens...
----
Brian K. Moran brian@mirror.TMC.COM
{mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA, 02140
Telephone: 617-661-0777 extension 122
"Won't somebody tell me, just who and what I did...
Why's this ring on my finger, and who's that screaming kid? "
From "Lost Weekend" by the Beat Farmers
---