New submission from Martin von Gagern <martin.vgag...@gmx.net>: When trying to decide whether or not a given file needs to be recompiled, the inode creation time should be taken into account along with the file modification time.
Scenario: Suppose you have three times, A < B < C < D. At time A, you package version 1 of foo.py. At time B, you package version 2. At time C you install version 1 onto some system, and byte-compile it for all users. Therefore foo.py has mtime A and ctime C, and foo.pyc has both mtime C. At time D you delete foo.py from version 1 and install version 2. Then you byte-compile it without force. At that time, foo.py has mtime B (because that was when it was packaged) but ctime D (because that was when the file was created). foo.pyc has mtime C (because that was when it was last modified). The current comparison compares only mtimes, sees C > B, and skips foo.py. With this patch in place, it will check for C > max(B, D), which is not the case, and thus recompile foo.c. In other words, max(st_mtime, st_ctime) can be interpreted as the last time a file at a given path was changed, either through modification of its contents (mtime) or deletion followed by recreation (ctime). Installation systems that overwrite files without deleting them before still are in the same trouble as before, but all others will benefit from this. See also: http://bugs.gentoo.org/256953 ---------- components: Library (Lib) messages: 80939 nosy: gagern severity: normal status: open title: compileall: consider ctime type: feature request versions: Python 2.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5128> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
