os.path.getmtime() ne retourne pas fraction de seconde

Question

J'ai compilé python 2.6.4 pour centos 5.3 et trouver ce problème que os.path.getmtime() ou os.stat(). M_time ne avoir la partie fraction. Selon docs, si os.stat_float_times() renvoie True, il doit retourner la valeur float. Dans mon cas, je le vois comme flottant, mais pas de fraction (c'est 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 

Il est également étrange que la sortie de stat() ressemble à un int. Sur Windows, je vois une fraction de la même version de python. Je cours centos au-dessus de colinux, cela pourrait-il jouer un rôle, ou est-ce un problème de construction python? Je n'ai pas trouvé de résultats pour le problème de colinux générique. Peut-être est-ce comment colinux configure le système de fichiers? De quoi aurais-je besoin pour vérifier dans ce cas?

Answer 1

Il s'agit d'une limitation de système de fichiers, plutôt que d'un fichier Python. Centos est toujours sur ext3, ce qui fournit des temps entiers. Vous pouvez le voir si vous affichez les mtimes avec ls. Essayez

ls -ld --full-time /tmp 

Sur ma ext3 boîte Centos, je reçois

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

Sur ma ext4 boîte Ubuntu, je reçois

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

Ceci est décrit dans le ext4 Wikipedia article:

Horodatage amélioré

Comme les ordinateurs deviennent plus rapides en général et que Linux est de plus en plus utilisé pour les applications critiques, la granularité des horodatages basés sur la seconde devient insuffisante. Pour résoudre ce problème, ext4 fournit des horodatages mesurés en nanosecondes. En outre, 2 bits du champ d'horodatage étendu sont ajoutés aux bits les plus significatifs du champ secondes des horodatages pour différer le problème de l'année 2038 pendant 204 années supplémentaires.