Antoine Pitrou <[email protected]> added the comment: Hmm, interesting. This is exactly what happened recently when debugging pyc timestamp issues under Windows: http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%202.7/builds/1204/steps/test/logs/stdio
Some decoding of the above crash: - the test would set the .py file's timestamps to 2**33 - this is truncated (module 2**32) and therefore should become 0 in the .pyc file's embedded timestamp - in reality, the .pyc file's embedded timestamps is equal to 4294963696. Which is 2**32 - 3600. As a sidenote, we don't have any tests that the pyc file is re-used when it is fresh enough. Perhaps by running an interpreter in a subprocess with "-v" we could examine the verbose messages printed out in import.c. > It seems as though the correct fix would be to use something like > GetFileInformationByHandle in place of the fstat calls in import.c. We must probably also replace the stat() call (through _Py_stat) with GetFileAttributesEx, or make _Py_stat re-use GetFileAttributesEx. ---------- components: +Windows nosy: +brian.curtin, pitrou, tim.golden priority: normal -> high stage: -> needs patch _______________________________________ Python tracker <[email protected]> <http://bugs.python.org/issue13863> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
