According to the python docs, os.stat() gives the following for st_ctime:
"|st_ctime| - platform dependent; time of most recent metadata
change on Unix, or the time of creation on Windows"
To reproduce:
1) touch foo
2) wait a minute
3) touch foo
4) use python's os.stat() on the file foo
cygwin's python 2.7.10 gives (me) the same number for mtime, ctime, and
atime:
posix.stat_result(st_mode=33276, st_ino=40532396646393057,
st_dev=1079873317, st_nlink=1, st_uid=1001, st_gid=513, st_size=0,
st_atime=1464482278, st_mtime=1464482278, st_ctime=1464482278)
However, cygwin's built-in stat command gives (correctly) the addtional
"birth time", which is different:
Access: 2016-05-28 20:37:58.748977000 -0400
Modify: 2016-05-28 20:37:58.748977000 -0400
Change: 2016-05-28 20:37:58.748977000 -0400
Birth: 2016-05-28 20:36:34.514159100 -0400
The non-cygwin version of Windows python from python.org (v2.7.11)
behaves correctly as per spec:
nt.stat_result(st_mode=33206, st_ino=0L, st_dev=0L, st_nlink=0,
st_uid=0, st_gid=0, st_size=0L, st_atime=1464482278L,
st_mtime=1464482278L, st_ctime=1464482194L)
Am I missing something, or is this a bug in cygwin's python? You could
argue that ctime is properly "change" and not "birth", but that's not
what the python spec says it should be on Windows.
More importantly, is there some other way of getting the "birth" time
from within cygwin's python? I'm currently calling out to the cygwin
shell using os.popen('stat "%W" <file>'), but that's not particularly
efficient, and it doesn't give subsecond precision.
mitch
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple