python os.path.getmtime()时间不变

时间:2013-09-27 20:52:29

标签: python python-2.7 os.path

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

在我的本地python命令行中,当我更改文件并调用os.path.getmtime(file_name)时,mtime的返回值已更改,以反映文件中的更改。

但是,当我在网络应用中调用os.path.getmtime()时,更改前后的返回值是相同的。我在网上进行了一些研究,并发现了一些建议,需要重新加载os模块才能更改要注册的文件。因此,在我的网络应用中,我重新加载了os模块,但mtime仍未反映对文件的更改。有没有其他人遇到此问题或知道解决方案?我在下面的网址中添加了一个代码段:

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

3 个答案:

答案 0 :(得分:1)

我没有足够的声誉将其添加为评论......

目前尚不清楚您的测试方式,您的网络应用的单个页面

  • print mtime
  • 更新文件
  • print mtime

或者

  • 只需打印mtime

如果您的网络应用测试流程

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

我的第一个猜测是Web客户端,代理或服务器缓存。

答案 1 :(得分:1)

我今天遇到了这个问题并发现了这个问题,所以我想我会在这里记录下来。我的案例是一个单元测试,所以它可能略有不同,因为它涉及的时间尺度比手动测试要小。

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

关于各种常见文件系统的时间分辨率的一些统计数据:

  • FAT32:2s
  • ext3:1s
  • exFAT:10ms
  • NTFS:100ns
  • ext4:1ns

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

如果<time for time stamp check> + <time for file write>小于时间分辨率,则文件可能看起来好像没有被修改。

我看到了这些可能的解决方案:

  • 在您正在撰写的文件的标题中包含更准确的修改时间。文件编写者甚至可以在写入之前检查文件是否已经存在,并将纳秒修改时间增加至少1,以保证更新(以时间戳精度为代价)。
  • 在其他地方存储每个文件的编辑频率。使用此编号可查看自上次检查后是否已编辑。请注意,可能无法以原子方式写入文件并一起更新修改计数。
  • 也许可以通过睡眠设计一些技巧,使得第一次时间戳检查和文件写入之间的时间始终至少是最小时间分辨率。这在很大程度上取决于您的设置类型,它将阻止该线程。

答案 2 :(得分:0)

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

服务器上更改前后文件的预期大小/ mtime(即在终端窗口中查看ls -l时)是相同还是不同。

如果使用此类命令行工具时的统计信息相同,则可能是您所考虑的文件未被编辑。

如果尺寸/ mtime不同,可以使用

os.stat(filename)

看看它是否给出了任何正确的值。