Hi Keith,
It sounds very much like what happens when two processes are trying
to write the file at the same time, which may result from a failure
in the locking protocol (e.g., the processes don't agree on the
locking mechanism).
- Are you running in server mode?
- Do you have other processes that might access the spool (e.g., an
IMAP server, users accessing the spool directly, etc.)?
- Do you have fast IO or locking options set?
- Did you install your own local delivery agent?
- If you are using server mode, you might try disabling it, more as a
diagnostic than a fix, to see if that stops the problem.
At 9:47 AM -0600 10/19/12, Keith Christian wrote:
On Thu, Oct 18, 2012 at 5:03 PM, Randall Gellens
<ra...@qti.qualcomm.com> wrote:
Hi Keith,
My guess is that something is stomping on the spool. Does this seem to
> happen to a set of users in particular? Are you running in
server mode? Do
you have other processes that might access the spool (e.g., an IMAP server,
users accessing the spool directly, etc.)? Do you have fast IO or locking
options set? Are you using an unusual local delivery agent?
You might try disabling server mode, more as a diagnostic than a fix, to see
> if that stops it.
Hi Randy,
Thanks for your quick reply.
Qpopper is running under Xinetd. I can't identify any common set of
users whose mailboxes have this problem. Further, the pattern of the
stray data that corrupts the mail file is not consistent. Every email
in the .mail file is a MIME encoded attachment if that helps.
A few examples of the corruption reported by Qpopper when a user tries
to log in:
1. Between messages, the end of base64 data usually has a
"---bOuNdArY---" line, a blank line, then the "From " line beginning a
new message. Usually there is some garbage, e.g. a few stray X-UIDL:
lines between "---bOuNdArY---" and the "From " line, confusing Qpopper
so that it can't find the "From " line.
2. Other times, it appears the block of base64 data isn't completely
written, e.g. some of the final lines of base64 aren't written, nor is
the "---bOuNdArY---" line written, either. This seemingly incomplete
base64 block is then followed immediately by the "From " line, no
blank line appears.
3. Or, the header, usually 30 lines, starting with "From " and on
line 30 the first line of base64 data appears, is truncated, with the
introductory lines above the base64 data missing. You obviously know
this: Those introductory lines in a normal message usually are:
Content-Type: audio/mp4;
name="stuff_stuff_stuff.mp4"
Content-Disposition: attachment; filename="stuff_stuff_stuff.mp4"
Content-Transfer-Encoding: Base64
Many-LINES-of-76-character-base64-data-ARE-here
Many-LINES-of-76-character-base64-data-ARE-here
Many-LINES-of-76-character-base64-data-ARE-here
Many-LINES-of-76-character-base64-data-ARE-here
Many-LINES-of-76-character-base64-data-ARE-here
Many-LINES-of-76-character-base64-data-ARE-here
---------------------bOuNdArY-------------------
Hope this explanation helps.
Keith
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Language is a virus from outer space. --William S. Burroughs
