Title: TypeError: utimes(): 3rd arg can't be coerced to long
Type: Severity: normal
Components: Core Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: pjenvey Nosy List: fwierzbicki, pjenvey, thijs, worlddominationkites
Priority: Keywords:

Created on 2008-11-08.18:20:24 by thijs, last changed 2008-12-16.22:04:29 by thijs.

File name Uploaded Description Edit Remove
et-jython.tar.gz thijs, 2008-11-23.15:41:27 trunk version of jython-elementtree r26
msg3761 (view) Author: Thijs Triemstra (thijs) Date: 2008-11-08.18:20:23
When trying to install jython-elementtree or setuptools trunk, or running our unit tests it reports the 
following error:

Traceback (most recent call last):
  File "./", line 53, in <module>
    setup(name = "PyAMF",
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 151, in setup
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 974, in run_commands
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 994, in run_command
  File "/home/buildbot/Buildslaves/pyamf/amd64-ubuntu-jython/build/setuptools-0.6c8-
py2.5.egg/setuptools/command/", line 56, in run
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/command/", line 517, in run
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 333, in run_command
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 994, in run_command
  File "/home/buildbot/Buildslaves/pyamf/amd64-ubuntu-jython/build/setuptools-0.6c8-
py2.5.egg/setuptools/command/", line 21, in run
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/command/", line 116, in install
    outfiles = self.copy_tree(self.build_dir, self.install_dir)
  File "/home/buildbot/Buildslaves/pyamf/amd64-ubuntu-jython/build/setuptools-0.6c8-
py2.5.egg/setuptools/command/", line 50, in copy_tree
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 385, in copy_tree
    return dir_util.copy_tree(
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 169, in copy_tree
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 174, in copy_tree
    copy_file(src_name, dst_name, preserve_mode,
  File "/usr/local/src/jython-trunk/dist/Lib/distutils/", line 172, in copy_file
    os.utime(dst, (st[ST_ATIME], st[ST_MTIME]))
  File "/usr/local/src/jython-trunk/dist/Lib/", line 534, in utime
    _posix.utimes(path, long(atime * 1000), long(mtime * 1000))
TypeError: utimes(): 3rd arg can't be coerced to long

For a full issue report see our buildbot log at

I'm logging this ticket against 2.5alpha3 because the 2.5beta0 version nr isn't available in the list, 
might want to add that as well. Exact revision nr I was using is 5557.
msg3762 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-09.00:17:17
Is this 64 bit java? I know there's an existing issue with utimes and 64 
bit java (on OS X, maybe others) -- though oddly enough this doesn't 
look like that issue at all.

I wasn't able to reproduce this on OS X 64 bit java (using jython trunk 
r5557, pyamf trunk).

Does the following simple case work?

import os
f = '/tmp/jython-foo'
open(f, 'w').close()
s = os.stat(f)
os.utime(f, (s.st_atime, s.st_mtime))

If you have a local Jython build and can reproduce the issue, it'd help 
to know what the actual arguments being passed to os.utime are (you 
could temporarily hack your to print them out)
msg3763 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-09.00:18:33
Also I'd like to double check what the value of 'os._native_posix' is on 
this platform
msg3767 (view) Author: Thijs Triemstra (thijs) Date: 2008-11-09.16:55:53
Yes it's a 64-bit machine. I put your test into a .py file and ran it 
with Jython and it didn't report any errors..

The results of the second request:

Jython 2.5b0+ (trunk:5557, Nov 8 2008, 16:33:47) 
[Java HotSpot(TM) 64-Bit Server VM (Sun Microsystems Inc.)] on 
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os._native_posix

The errors with jython-elementtree went away because they recently 
changed the installation procedure (now using an instead of 
setuptools-based I'll see if I can create a better reproducible test for this issue.
msg3784 (view) Author: Thijs Triemstra (thijs) Date: 2008-11-17.23:25:49
Alright so I'm able to reproduce this with jython-elementtree 
( r26 and jython r5587. 
running 'jython install' throws this error. Using setuptools-
0.6c8. Not sure if it's then a jython, jython-elementtree or setuptools 
issue, so let me know if I should open a ticket against a different 
project, but it all points to jython it seems.
msg3794 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-20.18:18:38
hippyhacker noticed stat results on this platform (64 bit linux) are 
occasionally returning huge numbers (for things like st_mtime):

This must be the cause of this problem, I can reproduce the error 
message on any platform by passing a huge long such as 7308549900279964261 to os.utime
msg3811 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-22.23:57:22
I have a Java 64/amd64 linux VM setup to work on this, I just need a 
file that can reproduce the problem. I'm positive it's the problem 
hippyhacker described, so I'm looking for a file that will return a huge 
long timestamp from stat

you should be able to tar up the file and send it to me (it'll preserve 
its timestamps), though hippyhacker tried and that didn't work (might 
have been his fault). It'd be nice if you could double check that the 
problem still happens after untarring the file
msg3813 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-23.00:00:14
(and I mean huge, as shown here: )
msg3837 (view) Author: Thijs Triemstra (thijs) Date: 2008-11-23.15:41:27
I tarred up the elementtree-jython trunk on my server using:

tar --atime-preserve -czvf et-jython.tar.gz jython-elementtree-trunk

I then downloaded it and tried to unpack it, which threw the following 

tar: jython-elementtree-trunk/build/lib/elementtree/ time 
stamp 2030-11-07 16:42:11 is 692845574 s in the future
tar: jython-elementtree-trunk/build/lib/elementtree/ 
implausibly old time stamp 1970-01-01 01:00:00
tar: jython-elementtree-
trunk/build/lib/elementtree/ implausibly old time 
stamp 1970-01-01 01:00:00
tar: jython-elementtree-trunk/build/lib/xml/etree/ 
time stamp 2026-01-20 09:52:31 is 541448194 s in the future
tar: jython-elementtree-trunk/build/lib/xml/parsers/ 
implausibly old time stamp 1970-01-01 01:00:00

So there's definitely something weird going on there. I attached that 
same tarball, I hope it helps solving this bug.. I have no idea how 
those timestamps became so screwed up, the time is and always has been 
correct on my server afaik. So I'm guessing Jython did something weird 
with the timestamps when trying to build the package? Just guessing..
msg3896 (view) Author: (worlddominationkites) Date: 2008-12-09.22:50:36
I'm getting the same problem trying to install django.

jython 5.5b0+ (trunk, Dec 9 2008, 16:54:43)
[Java HotSpot(TM) 64-bit Server VM (Sun Microsystems Inc.)] on 

django/trunk r9619

when I typed
# jython install
there were lots of

"copying django/this/that -> build/lib/django/this/that"

then, build/lib/django/contrib/csrf/ throws up a traceback, 
with line 542 of
_posix.utimes(path, long(atime * 1000), long(mtime * 1000))


TypeError: utimes(): 3rd arg can't be coerced to long

I stuck some print statements into, and 

DEBUG: mtime=7310012245875128690

what? Checking with stat
# stat build/lib/django/contrib/csrf/
  File: `build/lib/django/contrib/csrf/'
  Size: 5037            Blocks: 24         IO Block: 4096   regular file
Device: 823h/2083d      Inode: 11255892    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( XXXX/  XXXX)   Gid: (  XXXX/   XXXXX)
Access: 2008-12-10 09:00:48.000000000 +1100
Modify: 7165064483007524707
Change: 2008-12-10 09:00:45.000000000 +1100

Hmm. Other files don't stat like that (XXX overtyped by me by the 
# stat build/lib/django/contrib/gis/
  File: `build/lib/django/contrib/gis/'
  Size: 12528           Blocks: 40         IO Block: 4096   regular file
Device: 823h/2083d      Inode: 11256021    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( XXXX/  XXXXXX)   Gid: (  XXX/   XXXXX)
Access: 2008-12-10 09:00:45.000000000 +1100
Modify: 1970-01-01 13:28:48.000000000 +1000
Change: 2008-12-10 09:00:45.000000000 +1100

That  that Modify time is not nonsence, but it's not right either. see 

# ls -l build/lib/django/contrib/csrf/
-rw-r--r--  1 XXXXXX XXXXX 5037 7165064483007524707 

# ls -l  build/lib/django/contrib/gis/
-rw-r--r--  1 XXXXXX XXXXX 12528 Jan  1  1970 

Yeah, right.

# touch build/lib/django/contrib/gis/
# ls -l build/lib/django/contrib/gis/
-rw-r--r--  1 XXXXXX XXXXX 12528 Dec 10 09:25 

OK then,
# touch build/lib/django/contrib/csrf/
# ls -l build/lib/django/contrib/csrf/
-rw-r--r--  1 A01417 eawmd 5037 Dec 10 09:26 

Another "jython install" failed the same way further down, in 
contrib/webdesign. So I went on a touch rampage all over build/lib, 
then "jython install" completed OK.

But why was "jython build" making dodgy MTIMES in the build 
directory when stat in the source files looks fine?

Why is coreutils giving me nonsence with some of these dodgy MTIMES 
(but not all of them)?
msg3928 (view) Author: Philip Jenvey (pjenvey) Date: 2008-12-15.19:27:45
I was finally able to reproduce this by manually setting a file to a 
huge timestamp. I later realized 64 bit CPython also allowed me to set 
these huge timestamps. This seemed to only work on Linux, other OSes I 
tried overflow back to smaller values

So the question is, who set the huge mtime value in the first place? 
Likely Jython -- but how? We already knew utimes had some issues on 64 
bit platforms, but how would it manage to set a timestamp to such a huge 
value if it runs into "3rd arg can't be coerced to long" on those huge 

I'm thinking maybe that jna-posix utimes bug we already knew about 
somehow fudged another value into a much larger timestamp value

So I've a) fixed the 64 bit utimes bug we knew about, and also b) fixed 
utimes to allow setting these huge timestamps (as 64 bit CPython also 
allows it). So hopefully a) solves fudging timestamps, if we were in 
fact doing it before, and b) allows fudged timestamps to just pass on 
through. r5768

pjenvey@lamp:~/src/jython$ ll /tmp/foo.test 
-rw-r--r-- 1 pjenvey pjenvey 0 7165064483007524864 /tmp/foo.test
pjenvey@lamp:~/src/jython$ stat !$
stat /tmp/foo.test
  File: `/tmp/foo.test'
  Size: 0         	Blocks: 0          IO Block: 4096   regular 
empty file
Device: 801h/2049d	Inode: 78731       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ pjenvey)   Gid: ( 1000/ pjenvey)
Access: 7165064483007524864
Modify: 7165064483007524864
Change: 2008-12-15 00:40:34.000000000 +0000
pjenvey@lamp:~/src/jython$ touch /tmp/foo.test2
pjenvey@lamp:~/src/jython$ ll !$
ll /tmp/foo.test2
-rw-r--r-- 1 pjenvey pjenvey 0 2008-12-15 19:23 /tmp/foo.test2
pjenvey@lamp:~/src/jython$ dist/bin/jython
Jython 2.5b0+ (trunk:5768, Dec 15 2008, 19:21:04) 
[Java HotSpot(TM) 64-Bit Server VM (Sun Microsystems Inc.)] on 
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat('/tmp/foo.test').st_mtime
>>> os.utime('/tmp/foo.test2', (_, _))
pjenvey@lamp:~/src/jython$ !-2
ll /tmp/foo.test2
-rw-r--r-- 1 pjenvey pjenvey 0 7165064483007524864 /tmp/foo.test2
msg3938 (view) Author: Thijs Triemstra (thijs) Date: 2008-12-16.22:04:28
Confirmed it works, cheers!
Date User Action Args
2008-12-16 22:04:29thijssetmessages: + msg3938
2008-12-15 19:27:46pjenveysetstatus: open -> closed
resolution: fixed
messages: + msg3928
2008-12-14 17:18:44fwierzbickisetcomponents: + Core
2008-12-09 22:50:37worlddominationkitessetnosy: + worlddominationkites
messages: + msg3896
2008-11-23 15:41:28thijssetfiles: + et-jython.tar.gz
messages: + msg3837
2008-11-23 00:00:14pjenveysetmessages: + msg3813
2008-11-22 23:57:23pjenveysetassignee: pjenvey
messages: + msg3811
2008-11-20 18:18:38pjenveysetmessages: + msg3794
2008-11-17 23:25:49thijssetmessages: + msg3784
2008-11-10 21:41:24fwierzbickisetnosy: + fwierzbicki
2008-11-09 16:55:53thijssetmessages: + msg3767
2008-11-09 00:18:33pjenveysetmessages: + msg3763
2008-11-09 00:17:18pjenveysetnosy: + pjenvey
messages: + msg3762
2008-11-08 18:20:24thijscreate