Issue 8002: on OSX the file creation date not available in os.stat (original) (raw)

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/52250

classification

process

Created on 2010-02-23 15:21 by klankschap, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg99925 - (view)	Author: Floris van Manen (klankschap)	Date: 2010-02-23 15:21
OSX has a different interpretation of the file creation date. a workaround is possible via libc.dylib stat64 but that in turn is not possible prior to OSX 10.5
msg99927 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2010-02-23 15:29
To be more precise: see . The OSX 10.5 introduces a new version of stat 'stat64' that exposes additional information to posix-style programs, amongst which is the file creation date. This field is not present in earlier editions of OSX and is also not present on other platforms. That is, the field is not the same as the "ctime" field which contains the timestamp for the last metadata change for a file.
msg100574 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2010-03-07 12:08
I've done some research: the st_birthtime field is available when the python executable is build using MACOSX_DEPLOYMENT_TARGET=10.5 (or later), not for 10.4. Adding support for st_birthtime for MACOSX_DEPLOYMENT_TARGET=10.4 is possible but requires significant code duplication in posixmodule.c. IMO it adding this support is not worth the effort or the additional code complexity.
msg100579 - (view)	Author: Floris van Manen (klankschap)	Date: 2010-03-07 13:25
On Mar 7, 2010, at 13:08, Ronald Oussoren wrote: > IMO it adding this support is not worth the effort or the additional code complexity. I do agree. We have to look forwards ... F
msg103523 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2010-04-18 19:36
I'm closing this issue as won't fix. The additional fields are available if you build from source and target 10.5 or later (set 'MACOSX_DEPLOYMENT_TARGET=10.5' when you run configure). My current plan is to have two installers for python 2.7 and 3.2: one is a 32-bit only version that runs on OSX 10.3 or later and one will be be a new version that supports 64-bit x86 code as well and requires OSX 10.5. This new installer won't suffer from this issue.