On Fri, Feb 29, 2008 at 2:44 PM, Fletcher Mattox
<fletcher(_at_)cs(_dot_)utexas(_dot_)edu> wrote:
The corruption seems to always be of the form:
\000 ... \000From user(_at_)dom(_dot_)ain date
where \000 is a the null byte. That is, we are seeing a series of nulls
(30 to 3000+) prepended to the message (or perhaps appended from the
previous message).
We deliver to the user's home directory mounted via NFS from a Network
Appliance file server.
This is probably related to some sort of caching issue. It's most
likely to occur when a mail reader truncates the file and releases the
lock, and then procmail grabs the lock, seeks to the end, and begins
writing. If the NFS server hasn't completed processing the file
truncation when the write begins, everything between the truncation
point and the seek point will be filled with NUL bytes.
A change in the operating system on either the client or the server,
in the way the NFS filesystem is mounted, or even in the email readers
(or pop/imap server, etc.) that people are using, could cause this to
begin happening even though you've never seen it before.
The fix is to be sure that the NFS filesystem is mounted noasync and
with attribute caching etc. turned off. You may also need to tune the
read or write block sizes. Depending on the version of NFS, the mount
may also need to be "hard" rather than "soft".
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail