"S.Toms" <tomas(_at_)primenet(_dot_)com> writes:
That depends on how the lock is created. If you don't sepcify the name
to use for a lock file, then it will be created using the name of the
mailfolder with .lock appended to the end. But all locks should appear in
the same location as the mailfolder the message is being placed in as
long as the MAILDIR variable hasn't changed during the parsing of
that particular message. For example, the following:
When using locallockfiles (as opposed to the 'regional' LOCKFILE
variable), it is impossible for MAILDIR to change between the setting
of the lock and the delivery.
:0:
* Subject:.*
Inbox
That will create a lockfile named "Inbox.lock" (or more precisely, the
lockfile name will be the expansion of "Inbox$LOCKEXT". LOCKEXT has a
default value of ".lock" and is basically never changed, so the above
is a rather safe statement.)
so if the MAILDIR variable is called out in your procmailrc file like the
following:
MAILDIR=$HOME/mail
then it would create a Inbox.lock file like this:
$MAILDIR/Inbox.lock
Um, not exactly. When you set MAILDIR to be $HOME/mail, the procmail
process will actually change its default directory to the expansion of
"$HOME/mail" via the chdir(2) system call. When it then creates the
lockfile "Inbox.lock", it'll end up in the directory $HOME/mail, but the
path by procmail is relative. This can make a differance if directories
are moved around while mail is delivered and is also a performance
enhancement -- absolute paths require more work on the kernel's side.
If you name the lock as in the following:
:0: Blah
* Subject:.*
Inbox
then a lock file called blah.lock would be created in the MAILDIR location
instead.
No, the lockfile will be named "Blah". Lockfile names are case-sensitive
and the ".lock" prefix is appended if and only if the lockfile name was
implicitly determined (that is, if no name was give after the second
colon, causing procmail to extract the filename from the action line).
Someone be sure to slap me if I messed this up in any way :) at least
thats the way I understood it from the procmailrc(5) man page.
The above was not meant to sting, as your exaplanation was actually
fairly good. You just need to watch the details.
Philip Guenther