os.path.getmtime () не возвращает доли секунды - PullRequest
3 голосов
/ 11 марта 2010

Я скомпилировал python 2.6.4 для centos 5.3 и обнаружил, что проблема os.path.getmtime () или os.stat (). M_time не имеет дробной части. Согласно документации, если os.stat_float_times () возвращает True, то он должен возвращать значение с плавающей запятой. В моем случае я вижу это как float, но без дробной части (это 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. На окнах я вижу дробную часть с той же версией Python. Я использую Centos поверх Colinux, это может сыграть свою роль, или это какая-то проблема сборки Python? Я не смог найти ни одного хита по общей проблеме colinux. Может быть, так Colinux настраивает файловую систему? Что мне нужно проверить в этом случае?

1 Ответ

6 голосов
/ 12 марта 2010

Это ограничение файловой системы, а не Python. Centos все еще на ext3, что обеспечивает целое число mtimes. Вы можете увидеть это, если отобразите mtimes с помощью ls. Попробуйте

ls -ld --full-time /tmp

На моей коробке ext3 Centos я получаю

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

На моем ext4 Ubuntu box я получаю

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

Это описано в статье ext4 Википедии :

Улучшенные метки времени

Поскольку компьютеры в целом становятся быстрее и Linux все чаще используется для критически важных приложений, степень детализации временных меток на основе становится недостаточной. Чтобы решить эту проблему, ext4 предоставляет временные метки, измеренные в наносекундах. Кроме того, 2 бита расширенного поля меток времени добавляются к старшим битам поля секунд меток времени, чтобы отложить проблему 2038 года на дополнительные 204 года.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...