Problems wth os.stat().st_mtime on Mac

[Michael Glassford]

The Python 2.5 News at
http://www.python.org/download/releases/2.5/NEWS.txt states that Python
2.5 was changed to "Use Win32 API to implement os.stat/fstat. As a
result, subsecond timestamps are reported, the limit on path name
lengths is removed, and stat reports WindowsError now (instead of OSError)."

Although not mentioned in the Python 2.5 News, apparently there was a
similar change on Mac that I'm having some problems with. On the Mac,
just as on Windows, os.stat().st_mtime now returns a float instead of an
integer. My problem is that the decimal part of the float is
inconsistent in two ways.

1) The more serious problem (for me), is that on two machines (PowerPC
Mac Mini running Tiger and Intel Mac Mini running Tiger), the decimal
part of the returned float always appears to be ".0". On an iBook
running Panther, however, the decimal part appears to be ".0" for many
files, but for other files it contains actual significant digits. For
example:

import os
f = open("/tmp/tmp.tmp", "w")
f.close()
print os.stat("/tmp/tmp.tmp").st_mtime

#Both Mac Minis: 1159536137.0
#iBook: 1159536233.08

a) Why the difference between machines?

Also, on the iBook, I created this listing:
x)).st_mtime, x
(1159466888.0, '502')
(1159469259.0, '505')
(1159472677.0, 'hsperfdata_build')
(1159466868.0, 'mcx_compositor')
(1159466908.0, 'SoftwareUpdateCheck.pkgcatalog')
(1159532547.2405169, 'test.xxx')
(1159536233.0794201, 'tmp.tmp')

b) Why do most files on this machine have ".0", while some (generally
those I created myself using Python 2.5, I think) don't?


2) Even on the same machine, the results are different depending on how
I access them. For example, after setting up as follows:

strPath = "/tmp/test.xxx"
f = open(strPath, "w")
f.close()

I get the following output:
(33188, 1822331L, 234881030L, 1, 505, 0, 0L, 1159532547,
1159532547, 1159533628)
#Note that the results are all integers, including mtime
1159532547.2405169
#The result has 7 decimal places

I understand how the results can be different: the os.stat() function
returns a posix.stat_result object, which gives back an integer value
for the mtime if you call __str__ or __repr__, or if you iterate on it;
and a float if you get the st_mtime attribute. But I would consider it a
bug that the results are different: a float should be returned in either
case.


Mike

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Although not mentioned in the Python 2.5 News, apparently there was a
similar change on Mac that I'm having some problems with. On the Mac,
just as on Windows, os.stat().st_mtime now returns a float instead of an
integer.

It's isn't really new; os.stat_float_times was introduced in Python 2.3.
What changed in 2.5 is that it is now true. See

http://docs.python.org/whatsnew/modules.html

a) Why the difference between machines?

You really have to delve into OSX to answer this question. Several
reasons are possible:
- there is a change in the operating system implementations
- you are using different Python versions
- you are using different file systems

b) Why do most files on this machine have ".0", while some (generally
those I created myself using Python 2.5, I think) don't?

Hard to tell. Maybe the software that created those files explicitly
set a time stamp on them, and failed to use the API that supports
subsecond resolution in setting those time stamps.

I understand how the results can be different: the os.stat() function
returns a posix.stat_result object, which gives back an integer value
for the mtime if you call __str__ or __repr__, or if you iterate on it;
and a float if you get the st_mtime attribute. But I would consider it a
bug that the results are different: a float should be returned in either
case.

That's for backwards compatibility: You shouldn't use the tuple
interface anymore, but use st_mtime for new code. This will always
be a float. OTOH, the tuple interface will continue to return
integers forever (or until the tuple interface is removed in Python
3000), as old applications will break. This breakage isn't theoretical:
when I introduced float into st_mtime, I first made the tuple be
float also, and it broke several applications within a week (even
though that code was just in the CVS trunk, and not released yet).

Regards,
Martin

 

[Michael Glassford]

It's isn't really new; os.stat_float_times was introduced in Python 2.3.
What changed in 2.5 is that it is now true. See

http://docs.python.org/whatsnew/modules.html

Thanks, I wasn't aware of os.stat_float_times. This helps me a lot,
since I can turn off the floating point times in places until
incompatible code can be fixed.

You really have to delve into OSX to answer this question. Several
reasons are possible:
- there is a change in the operating system implementations

Possible, I guess, although I don't know how to find out and there's
likely nothing I could do about it even if I did.

- you are using different Python versions

Python 2.5 on both.

- you are using different file systems

This is the first thing I thought of, but all of the drives are
formatted using "Mac OS Extended (Journalled)", which I assumed meant
they are using the same file system.

Hard to tell. Maybe the software that created those files explicitly
set a time stamp on them, and failed to use the API that supports
subsecond resolution in setting those time stamps.


That's for backwards compatibility: You shouldn't use the tuple
interface anymore, but use st_mtime for new code. This will always
be a float. OTOH, the tuple interface will continue to return
integers forever

<snip>

OK, thanks for the explanation.

Mike