[ python-Bugs-1057992 ] os.utime() doesn't work on WinME

[SourceForge.net]

Bugs item #1057992, was opened at 2004-11-01 04:06
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057992&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.utime() doesn't work on WinME

Initial Comment:
>>> from os import stat, utime
>>> utime('fi.txt', (1099285201, 1099210995))
>>> stat('fi.txt').st_atime
1099285200
>>> stat('fi.txt').st_mtime
1099210996

----------------------------------------------------------------------

>Comment By: Facundo Batista (facundobatista)
Date: 2004-11-03 12:35

Message:
Logged In: YES 
user_id=752496

utime() works; you just' need to specify a greater time change.

I propose to close this bug and update the utime docs with
something like:

"Be aware that the resolution of the specified time depends
of the filesystem (for example, in FAT32 the access time has
a 1-day resolution: you'll not be able to specify the atime
with more detail than that)".


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-11-02 01:28

Message:
Logged In: YES 
user_id=31435

It's specifically *write* times that have a 2-second resolution 
on FAT, and write times are what I guess are important for 
the traceback test.

*Access* time has stinking 1-day resolution on FAT (no 
kidding).  So, since I figure I'm in the same time zone as 
Raymond, and FAT stores file times in local time (but NTFS 
uses UTC), it's not a coincidence either that the hour, minute 
and second fields are all 0 here (using the access time 
Raymond got):

>>> time.localtime(1099285200)
(2004, 11, 1, 0, 0, 0, 0, 306, 0)

You would have to feed utime an access time at least a day 
removed from that to conclude that utime doesn't change 
access time on FAT.  The access time you tried to set was 
also a local time on 2004 Nov 01:

>>> time.localtime(1099285900)
(2004, 11, 1, 0, 11, 40, 0, 306, 0)

so it's expected that you'd lose the 0:11:40 part on FAT -- 
and you did.

IOW, there's not yet evidence here that os.utime() doesn't 
work as well as it possibly can with a FAT filesystem.

File times on Windows are a godawful mess.  For more fun, 
see the docs:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/sysinfo/base/file_times.asp

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-01 23:52

Message:
Logged In: YES 
user_id=752496

Same behaviour here (not updates atime): Win2K SP4, on Fat32...


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-11-01 12:34

Message:
Logged In: YES 
user_id=80475

Yes.  There is a two second resolution.
It looks like mtime is updating but not atime:


>>> from os import stat, utime
>>> stat('fi.txt')
(33206, 0L, 2, 1, 0, 0, 14225L, 1099285200, 1099210600,
1099210993)
>>> utime('fi.txt', (1099285900, 1099210800))
>>> stat('fi.txt')
(33206, 0L, 2, 1, 0, 0, 14225L, 1099285200, 1099210800,
1099210993)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-11-01 11:34

Message:
Logged In: YES 
user_id=31435

Are you using FAT32 (or FAT) as your file system?  If so, 
those record file write times to 2-second resolution, so it's 
not a coincidence that the times you get back are always 
even.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057992&group_id=5470