Le jeudi 19 mai 2011 22:21:16, Jörg Schütter a écrit : > Hello Thomas,
Hello Jörg, > [SNIP] > > Looks like it also happens with small files. Since it doesn't > take so long to copy them, I never detected this. > > Original file > -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.443949038 +0200 > BIG_FILE use cp > -rw-r--r-- 1 joerg joerg 4222414848 2011-05-19 22:01:50.614892869 +0200 > BIG_FILE_cp use cp -p > -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.443949038 +0200 > BIG_FILE_cp_p use gcp > -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.000000000 +0200 > BIG_FILE_gcp use gcp --preserver=timestamps > -rw-r--r-- 1 joerg joerg 4222414848 2011-04-23 09:36:28.000000000 +0200 > BIG_FILE_gcp_preserve_timestamps > > Original file > -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.098747179 +0200 SMALL_FILE > use cp > -rw-r--r-- 1 joerg joerg 296 2011-05-19 22:05:57.214409519 +0200 > SMALL_FILE_cp use cp -p > -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.098747179 +0200 > SMALL_FILE_cp_p use gcp > -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.000000000 +0200 > SMALL_FILE_gcp use gcp --preserver=timestamps > -rw-r--r-- 1 joerg joerg 296 2011-04-22 11:21:45.000000000 +0200 > SMALL_FILE_gcp_preserve_timestamps This is very valuable information, thanks. So I checked and I can say python (at least python 2.6) return modification and access time precised at the second, not more. This is true even if stat_float_times returns true (which is the default on python >= 2.5). So for me the bug is in python. I will try to submit (if no bug report already exist) a bug report on this issue and in the mean time I will add a note in the man that resolution of access/modification time is the second. Note that the differents OS could be treated separately and use real system call (via subprocess or the like) to get the time as given by the OS but it would be bad for portability and rather overkill for just gaining nanosecond precision. Also, it would benefit much more people to solve this in python. Does this solution sounds fine to you (more documentation + bug forwarding)? > > Regards > Joerg Best regards. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org