Community
Participate
Working Groups
Eclipse seems to be slightly incompatible with command line cvs client. When I do checkout or update using cvs and then refresh relevant files in Eclipse some of them are marked as locally modified. Here are steps to reproduce the problem 1. Using command line, go to C:\temp and do cvs -z3 -d :pserver:anonymous@cvs.jboss.sourceforge.net:/cvsroot/jboss co buildmagic/build 2. In eclipse, create new project "buildmagic" with non-default location C:\temp\buildmagic 3. Select project "buildmagic" in navigator, right click, Team, Share project..., Finish. 4. Note that file buildmagic/build/build.xml is marked as dirty while buildmagic/build/build.bat is clean. I did some digging and it looks like this problem has to do with timezone and daylight saving. My computer is configured to use "Eastern time (US & Canada)" with automatic daylight saving adjustment. Apparently Eclipse (or JDK?) is failing to consider daylight saving which happens from Apr07 to Oct27 while command line utility does correct time adjustment. Specifically, version 1.4 of buildmagic/build/build.xml was committed at "Tue Oct 8 00:19:04 2002" according to CVS/Entries. If I check with windows explorer this file's "last modified" timestamp is "Monday, October 07, 2002, 8:19:04 PM" local time which is correct. However, if I check the same file in Eclipse, then last modified timestamp is "October 7, 2002 9:19:04 PM" which is one hour off. I also checked with debugger and this one hour diff is exactly what makes EclipseFile.isModified(ResourceSyncInfo) return true. Hope this little analysis helps. PS: Win2k SP2, Eclipse 200212181304, Sun JDK 1.4.1_01, cvs 1.11.1p1 (client).
See also http://developer.java.sun.com/developer/bugParade/bugs/4242143.html.
This may be a duplicate of 5337. Assigning for further assessment.
I am running NTFS. Btw, I spent some time on this and I am pretty sure that the problem is due to difference in behaviour of (C functions) stat/utime used by command line cvs client and File.lastModified/setLastModified used by Eclipse. Basically, under Windows with auto daylight saving stat returns different values for the same file when daylight saving is on and when it is off and File.lastModified tries to compensate the difference. I guess the solution would be to use JNI to query/set last modified timestamp under Windows when the operation is related to content of CVS/Entries.
Let me restate your findings just to confirm that I understand you correctly. If I have a file whose timestamp is "Monday, October 07, 2002, 8:19:04 PM" then the stat/utime function will return "Monday, October 07, 2002, 8:19:04 PM" with daylight savings time turned on and "Monday, October 07, 2002, 9:19:04 PM" with daylights savings time turned off. For the same file, Java will always return "Monday, October 07, 2002, 9:19:04 PM". Is this correct?
Pretty much, with an exception that I compared seconds returned by stat with milliseconds returned by lastModified. Specifically, today (2 Jan 2003) stat says "1034036344" and File.lastModified says "1034039944000". If I turn clocks on my computer to (2 Jul 2003), stat and File.lastModified agree on "1034039944(000)". I've included my test "programs". Note that I used "gcc -mno-cygwin" to compile C. "-mno-cygwin" suppresses Posix compatibility layer provided by Cygwin and should not be necessary with native win32 C compiler (which I do not have). ----------- daylight.c ------- #include <sys/stat.h> #include <sys/types.h> #include <stdio.h> void main() { struct stat s; stat("C:\\temp\\buildmagic\\build\\xml.bat", &s); printf("st_atime %u, st_ctime %u, st_mtime %u\n", s.st_atime, s.st_ctime, s.st_mtime); } ------------------------------ ----------- Daylight.java ------- package test.daylight; import java.io.File; public class Daylight { public static void main(String[] args) throws Exception { System.out.println(new File ("C:\\temp\\buildmagic\\build\\build.xml").lastModified()); } } ------------------------------
*** Bug 77570 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 15133 ***
