I understand switching to Director is suggested, but that's not really feasible (in a reasonable timeframe, anyway) for a mail cluster like ours that requires procmail and processes over 1.5 million emails/day. It's probably worth mentioning that the bug is easily triggered by writing an email w/ dovecot-lda and the test user is isolated from any imap/pop3 access.
I'm happy to debug further if need be, but even if these null bytes aren't written by dovecot it seems that this NFS behavior has existed long enough that it would make sense for dovecot to handle the situation more smartly than it is.The patch I wrote is little more than an adaptation of what's
already in place for handling extension fields, so it doesn't seem to me
like a crazy change to make.
This snippet of an strace seems to catch the problem the first time it's encountered, fwiw. The number of null bytes is *always* equal to the number of bytes in the string LDA is about to write to the uidlist, which implies to me that it's independent from what any other host might be doing with the file at the time.
stat("/mnt/dale/dale2/buttersnap/x9508664/Maildir", {st_mode=S_IFDIR|S_ISGID|0710, st_size=4096, ...}) = 0
chown("/mnt/dale/dale2/buttersnap/x9508664/Maildir", 9508664, -1) = 0
openat(AT_FDCWD, "/mnt/dale/dale2/buttersnap/x9508664/Maildir/dovecot-uidlist", O_RDONLY) = 13
close(13) = 0
stat("/mnt/dale/dale2/buttersnap/x9508664/Maildir/dovecot-uidlist", {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
lseek(11, 0, SEEK_SET) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
pread64(11, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 8192, 10510) = 63
pread64(11, "", 8129, 10573) = 0