On Mon, 14 Feb 2000, Philip Guenther wrote:
pg> "S.Toms" <tomas(_at_)primenet(_dot_)com> writes:
pg> > That depends on how the lock is created. If you don't sepcify the name
pg> >to use for a lock file, then it will be created using the name of the
pg> >mailfolder with .lock appended to the end. But all locks should appear in
pg> >the same location as the mailfolder the message is being placed in as
pg> >long as the MAILDIR variable hasn't changed during the parsing of
pg> >that particular message. For example, the following:
pg>
pg> When using locallockfiles (as opposed to the 'regional' LOCKFILE
pg> variable), it is impossible for MAILDIR to change between the setting
pg> of the lock and the delivery.
pg>
pg>
You know, I wasn't positive about that, seemed kinda weird but the
description in the man page kinda gives the idea it can be changed at any
time.
pg> > :0:
pg> > * Subject:.*
pg> > Inbox
pg>
pg> That will create a lockfile named "Inbox.lock" (or more precisely, the
pg> lockfile name will be the expansion of "Inbox$LOCKEXT". LOCKEXT has a
pg> default value of ".lock" and is basically never changed, so the above
pg> is a rather safe statement.)
pg>
pg>
pg> >so if the MAILDIR variable is called out in your procmailrc file like the
pg> >following:
pg> >
pg> > MAILDIR=$HOME/mail
pg> >
pg> >then it would create a Inbox.lock file like this:
pg> >
pg> > $MAILDIR/Inbox.lock
pg>
pg> Um, not exactly. When you set MAILDIR to be $HOME/mail, the procmail
pg> process will actually change its default directory to the expansion of
pg> "$HOME/mail" via the chdir(2) system call. When it then creates the
pg> lockfile "Inbox.lock", it'll end up in the directory $HOME/mail, but the
pg> path by procmail is relative. This can make a differance if directories
Ahh, I always thought it was explicit. So when procmail starts out,
where exactly is it relative to? .../bin/procmail, $HOME, or where the
.procmailrc file is located? ( ... represents wherever )
pg> are moved around while mail is delivered and is also a performance
pg> enhancement -- absolute paths require more work on the kernel's side.
pg>
pg>
So you could actually get better perfromance or quicker delivery by
assinging the correct location to MAILDIR then. Thanks, something for me
to look at
pg> > If you name the lock as in the following:
pg> >
pg> > :0: Blah
pg> > * Subject:.*
pg> > Inbox
pg> >
pg> >then a lock file called blah.lock would be created in the MAILDIR location
pg> >instead.
pg>
pg> No, the lockfile will be named "Blah". Lockfile names are case-sensitive
pg> and the ".lock" prefix is appended if and only if the lockfile name was
pg> implicitly determined (that is, if no name was give after the second
pg> colon, causing procmail to extract the filename from the action line).
pg>
pg>
Heh, oops, that was a typo :/
pg> > Someone be sure to slap me if I messed this up in any way :) at least
pg> >thats the way I understood it from the procmailrc(5) man page.
pg>
pg> The above was not meant to sting, as your exaplanation was actually
pg> fairly good. You just need to watch the details.
pg>
pg>
Thanks, I'm still learning and by posting what I did know, I found out
how accurate I was which helps me even more.
pg> Philip Guenther
pg>
--
S.Toms - tomas(_at_)primenet(_dot_)com - www.primenet.com/~tomas
SuSE Linux v6.3+ - Kernel 2.2.14
Don't worry about the world coming to an end today. It's already
tomorrow in Australia.
-- Charles Schultz