Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 28903

Summary:	[CVS Core] invalid dirty indicator after checking out using command line cvs
Product:	[Eclipse Project] Platform	Reporter:	Igor Fedorenko <igor>
Component:	Team	Assignee:	Platform-VCM-Inbox <platform-vcm-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P4	CC:	roger.stoffers
Version:	2.1
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Igor Fedorenko

2002-12-29 13:01:47 EST

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).

Comment 1 Igor Fedorenko

2002-12-31 17:41:18 EST

See also http://developer.java.sun.com/developer/bugParade/bugs/4242143.html.

Comment 2 Sonia Dimitrov

2003-01-02 13:21:12 EST

This may be a duplicate of 5337.  Assigning for further assessment.

Comment 3 Igor Fedorenko

2003-01-02 13:42:50 EST

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.

Comment 4 Michael Valenta

2003-01-02 15:24:01 EST

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?

Comment 5 Igor Fedorenko

2003-01-02 16:18:39 EST

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());
    }
}
------------------------------

Comment 6 Michael Valenta

2004-11-03 09:16:39 EST

*** Bug 77570 has been marked as a duplicate of this bug. ***

Comment 7 Michael Valenta

2005-05-10 14:21:25 EDT


*** This bug has been marked as a duplicate of 15133 ***