[PATCH] fix an unnecessary lookup caused by non-integer mtime returned by os.stat

Benoit Boissinot bboissin at gmail.com
Wed Oct 15 17:10:37 CDT 2008


On Wed, Oct 15, 2008 at 11:10 PM, Dov Feldstern <dfeldstern at fastimap.com> wrote:
> # HG changeset patch
> # User Dov Feldstern <dfeldstern at fastimap.com>
> # Date 1224104241 -7200
> # Node ID 4ee66eba1e33605d6f46d91005e97d54e83fd2fe
> # Parent  e786192d995d8440a461f051bd43db19b91e4cd8
> fix an unnecessary lookup caused by non-integer mtime returned by os.stat
>
> In python 2.5, stat.st_mtime returns type float. If the FS also supports
> sub-integer stat values, then the actual values returned may be non-integer.
> However, when dirstate is written to disk, the mtime is stored as an integer.
> This means that comparisons between the mtime returned by stat and those
> stored in dirstate can fail even if the file hasn't been touched since
> the last commit.
>
> A partial solution for this was provided way back in 882e703eaa94 (about
> two years ago): the time returned by stat is converted to int, and thus
> when compared with the value read from dirstate's persistent storage, both
> values are ints and the comparison returns the correct result.
>
> However, there is still a problematic scenario: if the comparison is
> performed *before* the dirstate is destroyed and the re-read from disk,
> then the value stored in it is still a float; and thus the "fix" actually
> causes the comparison to fail, because we compare the stored float with
> the int-converted stat.mtime.

I agree with your analysis.

>  Conversely, the new parse_dirstate also
> converts stat.st_mtime to int --- so we can't be sure of stat's type,
> either!

I am not sure for that part, parse_dirstate() shouldn't change the type of
the time returned bye os.stat(). It only converts the file stored to the actual
dirstate structure.
>
> Therefore, the current fix is to apply int() to both time and stat.st_mtime
> and only then compare them...
>

So I think doing:
if time != type(time)(st.st_mtime)

should work:
1) if the time value comes from dirstate, it will be a int and be compared with
the rounded down value
2) if the time value comes from a stat call, it might be a float so it won't be
rounded

It would be nice to figure out the problem with parse_dirstate()

regards,

Benoit


More information about the Mercurial-devel mailing list