I am busy setting up an automatic mail retrieval system at home. It will
collect email from a number of different remote POP mailboxes and
deliver it to the appropriate local users.
getmail seems to fit the bill, and I have a system up and running to do
just that -- it collects email and puts it into the appropriate
/var/spool/mail/$USER mbox file.
Now, getmail allows for two different types of file locking for the
/var/spool/mail/$USER file: flock and lockf. flock uses a lock file,
while lockf uses fcntl locking, which I gather is some internal kernel
feature.
Also, the getmail manual [1] warns that other programs using the mbox
file must use the same type of locking, to prevent them from accessing
the file simultaneously and causing corruption. It encourages you to ask
the system administrator what type of file locking the system uses.
I AM the system administrator and I don't know what type of file locking
it uses. I have not been able to discover the answer with a number of
Google searches.
Can anyone suggest a search string, or just tell me what type of mbox
file locking Ubuntu Intrepid uses for mbox files in /var/spool/mail?
An alternative suggested by getmail is to deliver mail to Maildirs
instead of mboxes. However, neither Evolution or Thunderbird can
retrieve mail from Maildirs into their own internal format, although
Evolution can access a Maildir store. So I would prefer that getmail
delivered to the /var/spool/mail mboxes.
A third alternative is just to hope that the mail client, getmail and
any other mail generators (I know that anacron occasionally sends email
to the system administrator) never access the mbox simultaneously, and
if they do, that Someone Else has already thought about the problem and
that the getmail default (lockf) is correct.
Stephen Irons
[1] http://pyropus.ca/software/getmail/configuration.html
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
