On Tue, Apr 21, 2009 at 7:00 AM, William Morgan <[email protected]> wrote: > I think you could be right. Using the size as part of the ID was > supposed to differentiate messages with the same timestamp, but it would > result in exactly the behavior you describe when polling. > > I think there's a much simpler scheme we can use that will also fix > this. I'll post a patch soon and we can see if it addresses the > problem.
I'd be very interested in this patch. In the meantime, I made some minor changes to maildir.rb, without changing the ID scheme. One problem was every time a maildir was polled, the most recent message (i.e., the one at cur_offset) would be treated as a new message again. I also changed last_offset to return an ID that would be one second later than the last message seen. These changes seem to have mostly fixed the lost message problem I was having, though I'm not exactly sure why. I've only had one lost message over the last couple of days, instead of the expected 10 or 20. I can't explain this one lost message, but I think it must be due to a different problem, unrelated to maildir handling. I was able to get sup to see this message again by doing a 'touch' on both the message itself and the containing maildir. I doubt that my changes would fix the race condition I described earlier, but I've avoided this problem by not running fetchmail in the background while sup is running. I'll send out my patch in a separate email. _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
