Bug 3914 - IMAP is compiled with -DIGNORE_LOCK_EACCES_ERRORS=1
Summary: IMAP is compiled with -DIGNORE_LOCK_EACCES_ERRORS=1
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-06 12:51 UTC by stone
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-07-29 07:27:24 UTC

Attachments (Terms of Use)

Description stone 1999-07-06 12:51:14 UTC
Looking at the IMAP Makefile it states:

Disable the "Mailbox vulnerable -- directory must have
1777 protection" warning which occurs if an attempt to
create a mailbox lock file fails due to an EACCES error.

WARNING: If the mail delivery program uses mailbox lock
files and the mail spool directory is not protected 1777,
there is no protection against mail being delivered while
the mailbox is being rewritten in a checkpoint or an
expunge.  The result is a corrupted mailbox file
and/or lost mail.  The warning message is the *ONLY*
indication that the user will receive that this could be
happening.  Disabling the warning just sweeps the problem
under the rug.

There are only a small minority of BSD-style systems in
which the mail delivery program does not use mailbox lock
files.  Linux is *NOT* one of these systems.  Do *NOT* set
this option on Linux or SVR4.

Can it be correct use that define?

I get lots of
Error opening or locking INBOX user=blah host=hostname
errors from my ipop3 daemon since upgrading to imap4.5

Comment 1 Preston Brown 1999-07-06 15:35:59 UTC
Jeff, this shouldn't matter because none of our mailers use lockfiles,
but instead the system-call locking functions, correct?

Comment 2 Cristian Gafton 1999-07-29 07:27:59 UTC
that is correct. all the mail delivery programs on a RH system are
synced up to fcntl. this leaves out the mail delivery over nfs, but if
you are delivering mail over nfs you are looking for trouble anyway
(since even lockfiles will not protect you from that - they do not
guarantee the atomicity of a lock in any way)

Note You need to log in before you can comment on or make changes to this bug.