Author petri.lehtinen
Recipients ajaksu2, akuchling, baikie, barry, loewis, nnorwitz, peter.ll, petri.lehtinen, r.david.murray, terry.reedy
Date 2012-06-25.19:13:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340651601.81.0.675938804435.issue1599254@psf.upfronthosting.co.za>
In-reply-to
Content
It seems to me that there are three separate issues here:

1) Concurrent access to a single-file mailbox will discard some messages even if locking is correctly used. This is demonstrated by mailbox-test.patch, which despite its age applies on top of 3.2 and fails (at least for me)

2) Detecting changes to mbox files is hard and should be improved.

3) When the TOC of an mbox is re-read, the message keys should probably be kept intact. Otherwise, the application would need to prepare for the fact that keys can change without notice in the middle of a loop, for example.

The first point is a serious bug that should be fixed somehow.

The second point has been discussed in greath lengths, but it strikes me that the mtime tracking has not been suggested. AFAIK, this is what most/all mbox readers do. The toc should be re-read when the mtime changes and/or is newer than atime.

The third point also sounds important, but might be tricky to implement.
History
Date User Action Args
2012-06-25 19:13:21petri.lehtinensetrecipients: + petri.lehtinen, loewis, barry, akuchling, nnorwitz, terry.reedy, baikie, ajaksu2, peter.ll, r.david.murray
2012-06-25 19:13:21petri.lehtinensetmessageid: <1340651601.81.0.675938804435.issue1599254@psf.upfronthosting.co.za>
2012-06-25 19:13:21petri.lehtinenlinkissue1599254 messages
2012-06-25 19:13:20petri.lehtinencreate