[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Antoine Pitrou added the comment: > I should add, Antoine's counter-example of a file that's renamed or > replaced already doesn't work either under OSX. So while this > solution won't address that (even more narrow) use case, it would at > least improve the existing situation for what I would l

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Erik Bray added the comment: I should add, Antoine's counter-example of a file that's renamed or replaced already doesn't work either under OSX. So while this solution won't address that (even more narrow) use case, it would at least improve the existing situation for what I would like to thi

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Erik Bray added the comment: Fair enough, but then I would propose removing the automatic cache invalidation based on mtime altogether. It's just not reliable enough--this caused previously working code to break unexpectedly, and only on a single platform at that. I'm fine with "importlib.in

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Antoine Pitrou added the comment: > Put another way, the cache associated with a FileFinder only keeps > track of the filenames in a directory, and not their individual > mtimes. So if a new file is added to the directory the cache should > be invalided. Likewise if a file is removed. True, bu

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Erik Bray added the comment: Put another way, the cache associated with a FileFinder only keeps track of the filenames in a directory, and not their individual mtimes. So if a new file is added to the directory the cache should be invalided. Likewise if a file is removed. If a file is modif

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Erik Bray added the comment: Why should modifying the file in place be expected to do anything with respect to the directory cache? If that module has already been imported then modifying it should not require the cache to be invalidated. If the file is modified *before* it's imported that's

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Brett Cannon added the comment: Antoine does make a good point: adding st_nlink could lead to some hard-to-discover bugs because something will work the first time when the file is added but then subsequently fail if you are modifying the new file in-place. I'm going to go with Antoine's think

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Antoine Pitrou added the comment: Well, importlib.invalidate_caches() is not a workaround, it's really the right way to solve your issue (for example if instead of writing a new module, you modify an existing one: st_nlink will then remain the same). -- ___

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Brett Cannon added the comment: [for anyone else who doesn't know what st_nlink is for: http://docs.python.org/3/library/stat.html#stat.ST_NLINK] Since it doesn't add stat overhead as it's just part of what os.path.stats() returns I'm fine with adding it to part of the invalidation scheme. Wha

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

Changes by Erik Bray : -- keywords: +patch Added file: http://bugs.python.org/file29286/94e671589c0e.diff ___ Python tracker ___ ___ P

[issue17330] Check st_nlink in addition to st_mtime to invalidate FileFinder cache

New submission from Erik Bray: This is vaguely related to issue14067, though the patch suggested there would make this problem worse, not better. This addresses a problem that cropped up on OSX in which some code that, for Good Reasons, generates a module in a package directory and then expect