3

我为 centos 5.3 编译了 python 2.6.4 并发现 os.path.getmtime() 或 os.stat().m_time 没有分数部分的问题。根据文档，如果 os.stat_float_times() 返回 True，那么它应该返回浮点值。就我而言，我确实认为它是浮点数，但没有小数部分（它是 0）。

In [3]: os.path.getmtime('/tmp') 
Out[3]: 1268339116.0

In [4]: os.stat('/tmp')
Out[4]: posix.stat_result(st_mode=17407, st_ino=508897L, st_dev=29952L, st_nlink=7, st_uid=0, st_gid=0, st_size=4096L, st_atime=1268101696, st_mtime=1268339116, st_ctime=1268339116)

In [5]: os.stat_float_times()
True

In [6]: os.stat('/tmp').st_mtime
Out[6]: 1268339116.0

stat() 输出看起来像一个 int 也很奇怪。在 Windows 上，我确实看到了具有相同 python 版本的小数部分。我在 colinux 上运行 centos，这可能会起作用，还是一些 python 构建问题？我找不到通用 colinux 问题的任何匹配项。可能是colinux如何配置文件系统？在这种情况下我需要检查什么？

4

1 回答 1

6

This is a filesystem limitation, rather than a Python one. Centos is still on ext3, which provides integer mtimes. You can see this if you display the mtimes with ls. Try

ls -ld --full-time /tmp

On my ext3 Centos box, I get

drwxrwxrwt 11 root root 69632 2010-03-11 13:16:30.000000000 -0800 /tmp

On my ext4 Ubuntu box, I get

drwxrwxrwt 16 root root 20480 2010-03-11 21:20:02.088188962 +0000 /tmp

This is described in the ext4 Wikipedia article:

Improved timestamps

As computers become faster in general and as Linux becomes used more for mission critical applications, the granularity of second-based timestamps becomes insufficient. To solve this, ext4 provides timestamps measured in nanoseconds. In addition, 2 bits of the expanded timestamp field are added to the most significant bits of the seconds field of the timestamps to defer the year 2038 problem for an additional 204 years.

于 2010-03-11T21:28:41.523 回答