Issue1567212

In our project we got some problems when a Jython file
was edited on a remote server using WinSCP and it set
atime and mtime of the file incorrectly one hour into
past. That made Jython to ignore changes because
already existing class file had a newer mtime. The
behaviour of WinSCP is likely to be a bug they've
introduced when trying to have a workaround for a
Windows bug/feature with the daylight saving time [1].
I posted a separate question to WinSCP forums [2] about
the issue but haven't yet got any definitive answers.
I've also sent a mail about this to jython-users
mailing list yesterday but for some reason it hasn't
gone through. 

[1] http://winscp.net/eng/docs/timestamp
[2] http://winscp.net/forum/viewtopic.php?p=12825

I investigated this issue a bit more and noticed that
it is very easy to reproduce the problem in Jython
simply with 'touch'. I also noticed that Python doesn't
have this problem and at that point decided to submit
this issue as a bug.

Example follows. Note that I've renoved some
non-relevant information from 'stat' outputs.

$ uname   
CYGWIN_NT-5.1

$ jython --version
Jython 2.2a1 on java (JIT: null)

$ python -V
Python 2.4.3

$ echo "var = 1" > x.py

$ echo "import x; print x.var" > tester.py

$ python tester.py 
1

$ jython tester.py 
1

$ stat x.py x.pyc x\$py.class 
  File: `x.py'
Access: 2006-09-28 20:36:49.690272200 +0300
Modify: 2006-09-28 20:36:38.537592200 +0300
Change: 2006-09-28 20:36:38.537592200 +0300
  File: `x.pyc'
Access: 2006-09-28 20:36:43.660952200 +0300
Modify: 2006-09-28 20:36:43.660952200 +0300
Change: 2006-09-28 20:36:43.660952200 +0300
  File: `x$py.class'
Access: 2006-09-28 20:36:49.690272200 +0300
Modify: 2006-09-28 20:36:49.690272200 +0300
Change: 2006-09-28 20:36:49.690272200 +0300

$ echo "var = 2" > x.py

$ touch -t 01010101 x.py  

$ python tester.py 
2

$ jython tester.py 
1

$ stat x.py x.pyc x\$py.class 
  File: `x.py'
Access: 2006-09-28 20:38:08.165152200 +0300
Modify: 2006-01-01 01:01:00.000000000 +0200
Change: 2006-09-28 20:38:04.353872200 +0300
  File: `x.pyc'
Access: 2006-09-28 20:38:08.165152200 +0300
Modify: 2006-09-28 20:38:08.165152200 +0300
Change: 2006-09-28 20:38:08.165152200 +0300
  File: `x$py.class'
Access: 2006-09-28 20:38:11.992052200 +0300
Modify: 2006-09-28 20:36:49.690272200 +0300
Change: 2006-09-28 20:36:49.690272200 +0300


Based on the above it seems for me that Jython compares
mtime of 'x.py' file and 'x$py.class' files when
deciding should it recompile the latter. In this case
the class file is thus not recreated even though py
file is newer (which could be seen from ctime). Python,
however, seems to check either both mtime and ctime or
only ctime.

I suppose that checking only the ctime would be ok for
Jython. It can be, AFAIK, updated only by the operating
system itself so no buggy program can reset it. One
problem of ctime is that it's updated also when content
of the file doesn't change, e.g. when only file
permissions are changed, and regenerating the file in
those situations is probably not needed. In my opinion,
however, recompiling the class file sometimes when
there's no need is far less severe problem than not
recompiling it when it really should.

Unfortunately ctime seems to have different semantics
on Windows than on Unix and most of the above is true
only in Unixes. 

PS: See for example [3] if you are not sure what are
the differences between atime, mtime and ctime.

[3] http://www.unix.com/showthread.php?t=20526

Confirmed; if you look at Python/import.c and getmtime.c, CPython does look at mtime.

Oops, actually I misread your bug report and am not really confirming it. 

CPython doesn't look at ctime at all; it looks at mtime, but records mtime in the .pyc file and then rebuilds if 
<pyc mtime> != <py mtime>.

For Jython: can we record the original mtime in the .class file through some extension mechanism?  Or, you could add a private attribute to the generated class... but that might mean importing the class in order to check the mtime.

We write the API version into the class file as an attribute, and then read it in org/python/core/imp.java.  Since it's the last attribute written, we just read it directly and don't actually need to import it through java. We should be able to do the same thing with the mtime.  

I can attest to being another unsuspecting victim of this, my example is 
the dupe #1024

assigning to myself so I don't lose track of this one.  should be a
relatively quick fix.

fixed in r6071