"S.Toms" <tomas(_at_)primenet(_dot_)com> writes:
On Mon, 14 Feb 2000, Philip Guenther wrote:
...
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.
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.
Only by a variable assignment, and there's no way to slip a variable
assignment in between the creation of a locallockfile and the invocation
of the recipe's action.
...
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 )
To quote the procmailrc(5) manpage's section on the variable defaults:
MAILDIR $HOME/
(Unless the name of the first success-
fully opened rcfile starts with `./'
or if -m has been specified, in which
case it defaults to `.')
(Hmm, that trailing slash seems spurious, I'll have to look into it.)
So, under normal conditions, MAILDIR starts out as $HOME.
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
I wouldn't stay up nights changing rcfiles to do so, but yes. Unless
you have a real deep directory nesting and a overloaded file server,
you probably won't notice.
Philip Guenther