On Mon, 14 Feb 2000 22:33:48 -0600 (CST), Glen Lee Edwards
<GLEdwards(_at_)uswest(_dot_)net> wrote:
Is it an accurate statement to say that you lock files, not
programs?
It is an accurate statement that whatever you want to accomplish by a
lock file, everything that accesses the thing you want to lock need to
adhere to the same locking conventions.
If you have special needs and are in a position to decide the
conventions yourself, you can lock anything.
To repeat and reinforce this, lock files by themselves accomplish
nothing much at all. Programmers write programs (and Procmail users
write Procmail recipes, but that's the same thing, even if you don't
want to think of yourself as a "programmer") which adhere to
conventions which say +for+ +example+ that if a lock file is there,
don't touch whatever the lock file protects. But not all programmers
do that. Anyway, the point is that dotlocking is a convention, not
something that you can use to protect things by force.
Generally, you use locks when you want to prevent something from
changing a file while you're working on it, but that's just one
application of locking.
For example, most Unix dialout programs will obey a lock on the modem
device, meaning that whichever user and program is currently using the
modem will be left alone until they remove the lock file. (Consider
what would happen on a system if somebody else started sending
commands to the modem while you are connected by that modem to another
site.)
But it only takes one ignorant programmer who writes a rogue program
which doesn't obey the lock file to spoil it for everybody else.
So a lock file /usr/local/bin/perl.lock (if you had permissions to
create it) would probably not prevent very many programs from running
Perl. It would prevent Procmail, in its standard configuration, from
appending data to /usr/local/bin/perl, if you attempted to do that
from a recipe with a lock file. Take out the lock file option, and
Procmail will happily attempt to append to this file.
Certainly, if +all+ your recipes which use Perl were coded to use the
same lock file, only one of them could run at a time. But that still
won't prevent recipes without a lock file from using Perl, or programs
which don't look for lock files (such as the shell :-) to happily
ignore your efforts inside your .procmailrc.
In addition to dotlocking, Procmail may use other locking schemes,
which may or may not be noticed by other programs. Kernel locking is
usually more effective than dotlocking (creating a file with a name
ending in dot-"lock") but as the manual pages for flock(2), lockf(2),
and fcntl(2) system calls will hopefully tell you, these locks too are
advisory on some systems, and may not work well over NFS (where the
same disk is shared by many hosts, each with its own kernel state
etc). [I'm shaky on this section. Somebody please correct me if
something here looks funny.]
procmail -v will tell you what locking methods your copy of Procmail
was configured to use. This is usually determined by the installation
program at compile time, but you can force it to drop certain locking
methods by setting some #defines in config.h
Hope this helps,
/* era */
Somebody with a better grasp of the history of Procmail and/or Unix
implementations could do well to attempt to explain why there are
three different system calls and why you'd want to avoid using some of
them some of the time.
--
Too much to say to fit into this .signature anyway: <http://www.iki.fi/era/>
Fight spam in Europe: <http://www.euro.cauce.org/> * Sign the EU petition