Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxc.cso.uiuc.edu!paul
From: paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
Newsgroups: comp.mail.sendmail
Subject: Re: Sendmail V5.65 + IDA 1.3.5 available for anon-FTP
Message-ID: <1990Nov7.172412.4592@ux1.cso.uiuc.edu>
Date: 7 Nov 90 17:24:12 GMT
References: <1990Oct17.044214.12339@ux1.cso.uiuc.edu> <MICHAEL.90Nov7110313@athene.uni-paderborn.de>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 32

michael@uni-paderborn.de (Michael Schmidt) writes:

>I just tried sendmail-5.65+ and noticed a change, that hits us. All
>ndbm databases are opened with O_RDWR. In 5.61++ it was O_RDWR only
>for DB_ALIAS and O_RDONLY otherwise. It happens, that we have a
>database on a read only filesystem and are updating the database
>otherwise. And we get an "can't open database" error.
>
>I changed daemon.c to try to open the database read only after a read
>write open failed (the tiny patch is included). Though, I'm not so
>sure, whether I do any harm to anything. Any comments?

This is a damned if you do, damned if you don't situation with regard to
portability.  I changed flags in daemon.c to increase portability for those
systems that half-way implement flock() in terms of either lockf() or
fcntl.

Only a pure Berkeley flock() allows an exclusive lock on a file opened 
read-only.  All others require read-write or write-only.  What I'll do
instead is reverse the order of the patch to try a read-only open first
and then retry as read-write should the flock() attempt fail.  That 
preserves as much as possible the original behavior.

Now if I could convince gdbm to leave locking to the application...

/pbp

--
         Paul Pomes

UUCP: {att,iuvax,uunet}!uiucuxc!paul   Internet, BITNET: paul@uxc.cso.uiuc.edu
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801-2910