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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4