Message1258

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