test_mailbox fails sometimes on FreeBSD. Recent example on AMD FreeBSD 8.2 3.x:
---------------
[200/354] test_mailbox
test test_mailbox failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_mailbox.py", line 905, in test_reread
    assert refreshed()
AssertionError
---------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/180/steps/test/logs/stdio

I think this relates #6896.
Maybe a two second resolution should be tried?

Well, it turns out that this sporadic failure is not a test bug, but a real bug in the mailbox module that the test is revealing.

This issue is the same one that motivated the changes in issue 6896.  Those changes, however, merely reduced the problem, but didn't solve it.

The fundamental problem is that mailbox is relying on comparing the system clock with the mtime.  But the mtime, it turns out, is not guaranteed to follow the system clock.  You can see this most easily if you think about, say, an NSF file system.  The mtime is set by the server's clock, and if the server's clock is different, the mtime won't match the local clock.  It appears to be also true for some reason on a vserver virthost: as reported in issue 6896, the mtime is sometimes set to a value a full second before the time.time() time.

Ironically this was discussed in the original bug report that introduced the mtime checking code (issue 1607951), and I found that bug on the first page of hits while searching for mtime/system clock synchronization problems.  The solution that Andrew proposed in that issue is slightly different from the one he actually implemented, but his proposed solution was also flawed.

The actual solution involves dealing correctly with two factors: the mtime "clock" is not synchronized with the system clock, and the mtime only has a resolution of one second.  The first means that when looking for changes to the mtime we must compare it to the previous value of the mtime.  The second means that if _refresh was last called less than a second ago by our clock (the only one we can query), we had best recheck because the directory may have been updated without the mtime changing.

I also added an additional delta in case the file system clock is skewing relative to the system clock.  I made this a class attribute so that it is adjustable; perhaps it should be made public and documented.

Attached is a patch implementing the fix.  It undoes the 6896 patch, since it is no longer needed.  At this writing my buildbot has run test_mailbox 50 times without failing, where before it would fail every third run or so.

Sadly, I had to reintroduce a 1.1 second fixed sleep into the test.  No way around it.  But it is a deterministic sleep, not a "hope this is long enough" sleep.

On Fri,  6 May 2011 04:44:00 +0200, R. David Murray wrote:
> [.] the mtime only has a resolution of one second.

You always say that!  But i'm pretty sure from somewhen long ago
that there are filesystems which have a two second time resolution.
And unless i'm mistaken that filesystem is still used widely.

> Attached is a patch implementing the fix.
> It undoes the 6896 patch

I've not yet tried your code but from looking at the patch it
seems to target towards a real approach.

> I also added an additional delta in case the file system clock
> is skewing relative to the system clock.  I made this a class
> attribute so that it is adjustable; perhaps it should be made
> public and documented.

On the other hand, if it shows up after almost five years that the
one second resolution solution doesn't work, and that simply
adjusting to a two second resolution is not smart enough to get
this fixed, then i would not go for something half-automatic which
a user needs to adjust manually, because how could a user do that?

Thus, in my view, if you are *really* looking forward to make
mailbox.py a *good* and *beautiful* thing then the timedelta in
between the filesystem and the host's time() must of course be
tracked-, and the fuzziness should be adjusted automatically.
E.g. similar http://linuxcommand.org/man_pages/adjtimex8.html.

> I also added an additional delta in case the file system clock
> is skewing relative to the system clock. 

In fact this idea could even be made public e.g. like this

    class ClockDrifter:
        def add_snapshot(self, exttime, loctime=None):
            if loctime is None:
                loctime = time.time()
            ...
        def drift_tendency(self):
            ...
        def drift_distance(self):
            ...

I could think of usages thereof.

Isn't this a bit out of scope for the mailbox module, though?  Mailbox is getting called at irregular intervals, and a clock monitor really wants to be a polling daemon of some sort, I think.  In which case a complete application system that used the mailbox library could adjust the _skewtime appropriately based on the output of a daemon, if it really cares that much.

I think we're well into YAGNI territory, though.  We are only concerned about how long one second is to the filesystem, and a filesystem that skews or jitters more than a tenth of a second over one second is probably pathological anyway.

As for the two second filesystem, my understanding is that is the FAT file system, and I say we just declare using maildir on FAT to be unsupported.  (But I suppose that should be documented).

(As a side note, atime on FAT has a resolution of 1 day, which kind of screws up your "new mail" signal....)

Oh, and to be clear: the problem wasn't that the one second interval was too short, the problem was that the times stamps of the files were being compared to the wrong check value (the system clock instead of their previous state).  The extra one tenth second is a "belt and suspenders" addition.

I am open to the argument that we should make it two seconds and a bit to support FAT, but how many people are going to use maildir on FAT?

I like all kind of single-screw solutions.
And i feel a bit uncomfortable with your usual tightness.
(0.1 seconds - i mean, come on)

> how many people are going to use maildir on FAT?

Dunno.
But it's maybe the lowest common denominator of mountable
readwrite filesystems.  Except for that MacBook i always had
a shared FAT partition on my private PCs.

All right, let's make it two seconds and a bit, then.

Why do you think a tenth of second is too small?  A clock with a skew of half that much would be badly broken.

I agree that it's fun to see pieces of code interacting like gears
in a transmission, but often it gets ugly due to the noise from
the outside which requires to add ugly fuzziness or honour stupid
design decisions.
Maybe an environment variable like PYMAILBOX_SKEW and then one
could run test_mailbox.py and see if it works for 0.01?? :)

New changeset a0147a1f1776 by R David Murray in branch '2.7':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/a0147a1f1776

New changeset 252451fef13f by R David Murray in branch '3.1':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/252451fef13f

New changeset 6907c43d1ee7 by R David Murray in branch '3.2':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/6907c43d1ee7

New changeset 214a34b26e1b by R David Murray in branch 'default':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/214a34b26e1b

Now we see if the buildbots agree with me that this is fixed.

I don't understand anything, but thanks for fixing it :-) (Or at least trying to fix it, buildbots will tell us.)

That's really a good one.
(In my eyes.)

This tracker - sorry!
(I surely will try to write and offer a patch for the tracker,
but first i need to understand that mailbox.py jungle for
#11935, next week.)

> Now we see if the buildbots agree with me that this is fixed.

There is a new failure today on a Windows Seven buildbot:

======================================================================
FAIL: test_reread (test.test_mailbox.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_mailbox.py", line 900, in test_reread
    self.assertFalse(refreshed())
AssertionError: True is not false

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3353/steps/test/logs/stdio

New changeset d2b0751174f6 by Petri Lehtinen in branch '2.7':
Update mailbox.Maildir tests
http://hg.python.org/cpython/rev/d2b0751174f6

New changeset b3c5e1c62839 by Petri Lehtinen in branch '3.2':
Update mailbox.Maildir tests
http://hg.python.org/cpython/rev/b3c5e1c62839