Community
Participate
Working Groups
builds 20011018, 20011025. OS: Win98/Win2K We have have problems when client machines are switched during Daylight Savings Time. This has happened to a bunch of users (all?) on Win98/Win2K and using builds 205/206. Users of WinXP and Linux seemed to be OK. When the workspace is started, all the resources appear to be out of sync with the filesystem. After you do a refresh local you are ok. But then you try and synchronize with the CVS repository and all your resources look like they are outgoing changes. Any resources which are really incoming changes from the server, are marked as conflicts.
I've placed a zip file on M:\accounts\johnart\public\target.zip, that contains the workspace I encountered the problem on. I reproduced the problem on 20011018 and 20011025 with this workspace. I'm running FAT32 on Windows 2000.
The problem will only affect Windows users with FAT or FAT32 file systems. NTFS stores the lastmodified timestamp in UTC but FAT stores in local time. So, NTFS users are OK.
The exactly same behaviour happens when using java.io.File.lastModified() with the IBM JDK 1.3 (i.e. works as expected on NTFS and fails on FAT).
Problem description and workaround as posted to news.eclipse.org on 2002-04-05. ------------------------ There is a problem with daylight savings time which users may experience. These issues are outlined below. Who will be affected: ================= Users who run with their workspaces living on FAT file systems and have their system clocks automatically adjusted for daylight savings time. Problem: ======== Both Core and CVS use the timestamps of the files on disk to represent the synchronization information (both local and remote) for resources in the workspace. As a result, some users will see strange behaviour after their local systems have adjusted their clocks for daylight savings time. Symptoms: ========== 1). All resources in the workspace will appear to be out of sync with the local file system. 2). When synchronizing with the CVS repository, all resources in the workspace will look like they contain outgoing changes. (a structure compare reveals that they haven't really changed) Resolution: ========== Work-around for problem #1: Users must perform a "Refresh from Local" on all of their projects in their workspace. Work-around for problem #2: - In Windows, go into your Date & Time properties, click on "Time Zone", and un-check the "Automatically adjust clock for daylight savings changes" check box. - Apply changes. - Refresh from local on all projects in the workspace - Team -> Synchronize with Repository. Note this should only show the changes which are "real" - Release your changes. - Change your time zone setting back. - Refresh from local on all projects in the workspace - Replace with -> Latest from Repository
See the following link for more info on the problem. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q129574 Investigate options post-2.0
Reopening for investigation. Either a solution or decision to README.
*** Bug 25469 has been marked as a duplicate of this bug. ***
*** Bug 26483 has been marked as a duplicate of this bug. ***
Marking as README.
We are using several Win NT maschines here that run on Eclipse 2.1 and CVS. All Harddisks are NTFS formatted. We have the same behaviour weekly on one maschine. So I fear the problem is not only DST related. Andreas Heidrich
Please open a new bug report if what you see is not related to daylight savings time. We don't plan on fixing the DST issue since it's really a problem with FAT32 drives and is not a problem originating in Eclipse or even the java VM. Since all your drives are NTFS, you're likely seeing something else.
OK, I will do so. Thanks for the advice.
*** Bug 45594 has been marked as a duplicate of this bug. ***
*** Bug 45576 has been marked as a duplicate of this bug. ***
*** Bug 90114 has been marked as a duplicate of this bug. ***
I have created a utility action that will reset the timestamps so the files are in-sync with CVS. Be warned however that this utility resets the timestamps for any file whose timestamp differs from the sync timestamp by 1 hour. There is a possibility that this could reset a file that is really dirty. Use at your own risk. To use the action, install the plugin at the URL belog and them run the CVS Util/Fix Timestamps command. http://dev.eclipse.org/viewcvs/index.cgi/platform-vcm- home/plugins/fixtimestamps.zip
*** Bug 90212 has been marked as a duplicate of this bug. ***
When adding your plugin to my Galileo installation, it will not be listed in the plug-in details and I don't get the Fix timestamps in the context menu. In my target, I still find the plugin...
The functionality from the "fix timestamps" plugin has since been integrated into the regular CVS plugin, and is performed automatically when you invoke Team->Synchronize.
