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:

 >>> for x in os.listdir("/tmp"): os.stat(os.path.join("/tmp", 
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:

 >>> os.stat(strPath)
 (33188, 1822331L, 234881030L, 1, 505, 0, 0L, 1159532547, 
1159532547, 1159533628)
 #Note that the results are all integers, including mtime

 >>> os.stat(strPath).st_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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problems wth os.stat().st_mtime on Mac

[Michael Glassford]

Martin v. Löwis wrote:
> Michael Glassford schrieb:
>> 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

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.

> 
>> 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

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.

> 
>> 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 



OK, thanks for the explanation.

Mike

-- 
http://mail.python.org/mailman/listinfo/python-list