python os.path.getmtime（）时间不变

我对python的

os.path.getmtime（）函数有一个很快的问题。我观察到一些奇怪的行为。我正在开发一个web应用程序，它定期检查某个文件是否已被修改，并根据该文件决定是否刷新

在本地python命令行中，当我更改文件并调用
os.path.getmtime（文件名）
时，
mtime
的返回值已更改以反映文件中的更改

但是，当我在web应用程序中调用
os.path.getmtime（）
时，更改前后的返回值是相同的。我在网上做了一些研究，发现一些东西表明需要重新加载操作系统模块才能注册对文件的更改。因此，在我的web应用程序中，我重新加载了
os
模块，但是
mtime
仍然不能反映对文件的更改。以前是否有其他人遇到过此问题或知道解决方案？我在下面的webapp中包含了一段代码片段：

import os

def function_name():
    reload(os)
    file_path = '/dir/lib/some_file.js'

    try:
        mtime = os.path.getmtime(file_path)
    except os.error:
        pass

    return mtime

也许您可以尝试获取文件中除mtime之外的一般统计信息，例如大小

在服务器上更改前后（即在终端窗口中查看ls-l时），文件的预期大小/mtime是否相同或不同

如果使用此类命令行工具时的统计数据相同，则可能是文件未在您认为的位置进行编辑

如果大小/时间不同，请使用

os.stat(filename)

看看它是否给出了正确的值
 我没有足够的声誉来添加此评论

目前还不清楚您是如何测试的，您的web应用程序的一个页面是否进行了测试


打印时间
更新文件
打印时间

或


只需打印mtime

如果您的web应用程序测试过程是


请求测试mtime页面
手动更新文件
请求测试mtime页面
请注意，mtime在两个页面视图上是相同的

我的第一个猜测是web客户端、代理或服务器缓存。
我今天遇到了这个问题，发现了这个问题，所以我想在这里记录一下。我的案例是一个单元测试，所以它可能略有不同，因为它涉及的时间尺度比手动测试小

修改时间受文件系统的限制。如果检查修改时间，然后写入少量数据，然后再次检查修改时间，则两个时间戳可能完全相等。如果第一次时间戳检查和写入结束之间的时间小于时间分辨率，则它们将相等

关于各种常见文件系统的时间分辨率的一些统计信息：


FAT32:2s
ext3:1s
exFAT：10毫秒
NTFS:100ns
ext4:1ns

您可以期望嵌入式系统使用FAT，并且具有2秒的时间分辨率。较旧的Windows系统将在2秒范围内。较新的Windows系统将具有100ns或10ms。较旧的UNIX系统通常具有1。较新的UNIX系统的分辨率为1ns

如果
+
小于时间分辨率，则文件可能会显示为未修改

我认为这些可能的解决办法是：


在正在编写的文件头中包含更准确的修改时间。文件编写器甚至可以在写入之前检查文件是否已经存在，并将纳秒修改时间至少增加1，以确保其更新（以时间戳准确性为代价）
将每个文件的编辑频率存储到别处。使用此数字可查看自上次选中后是否对其进行了编辑。请注意，可能无法以原子方式写入文件并同时更新修改计数
也许可以用sleep设计一些技巧，例如，第一次检查戳记和文件写入之间的时间总是至少是最小时间分辨率。这在很大程度上取决于您的设置类型，并且会阻塞线程
不，重新加载
os
模块与此无关。啊，好的。是的，我在一篇python文档中读到，
os.environ
仅在加载os模块时设置，我认为这可能与此有关。
os.path.getmtime（）
不会缓存任何内容。它只返回
os.stat（filename）.st\u mtime
os.stat（）
不缓存任何东西，它只是调用C库，C库向操作系统询问这些信息。您使用的是什么操作系统？我记得有些操作系统会延迟更新
mtime
直到文件关闭后。我正在Mac上开发。