[Python-Dev] Suggestion: stopping to trust os mtimes

[Greg Stein]

On Fri, 2 Jun 2000, Peter Funk wrote:
> Moshe Zadka wrote:
> > Trusting OS-based mtimes for .pyc caching has some inherent problems.
> > (Clock syncing and similar) Frankly, though I've never been bitten by
> > this, it does give me an uncomfortable feeling. What if, instead, we'd use
> > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of
> > problems is miniscule compared to the real problems clock syncing has
> > already caused. (I think I remember some problem with .pyc's on IIS, but
> > I may just be hallucinating)
> 
> The timestamp is returned by simply 'stat'ing the .py file.  If you
> want more, you actually would have to open the .py files all the time.
> This would be trading a big performance penalty for a security, that
> will almost always not needed.  In Unix many sub systems (for example
> 'make' depend on a monotone system clock.  A random jumping clock
> would break many of them anyway.

He does have a point, but I think the wrong solution :-)

While the clock may be monotonically increasing on one system, it isn't
always the case when things like NFS come into play.

I recall a case back '95 when I was editing a .py over an NFS mount and
running the code on the target machine. The clocks on the two boxes were
off by about three seconds. I was going thru the edit/run/edit/run cycle
so quickly, that at one point, I saved a .py file that was older than the
associated .pyc file.

Needless to say, I was really confused that my recent edit didn't produce
the desired result :-)

Cheers,
-g

p.s. and no, I don't know why the internal timestamp didn't take effect

-- 
Greg Stein, http://www.lyra.org/