Community
Participate
Working Groups
On Linux there appears to be a problem whereby Eclipse incorrectly identifies the cvs files used to store the structure and changes of a cvs project as actual source code files. e.g. 1) Start Eclipse with a clean workspace. 2) Create an empty Java project with /src and /bin subdirectories. 3) Connect to a CVS server and checkout some code into the /src directory of your project. 4) Shutdown Eclipse. 5) Restart Eclipse. 6) Eclipse now shows all the hidden cvs files and directories that are used to save the cvs structure as part of your project. I've also seen this problem occur under an earlier version of Eclipse when you use the refresh button of the package explorer view. (The extra files appear under all views / perspectives though - e.g. team synchronizing.) OS: IBM Open Client v1.0 PR (Based on RHEL 4) Machine: Pentium IV T4p laptop Eclipse Version: 3.1.0 Build id: I20050627-1435
We didn;t have time to address this in 3.2.
I have just had this problem again while refreshing my workspace. As I run backups on my machine I got hold of my latest backup and tried copying sections of the workspace back until to see if I could get the problem to disappear. I thought the problem might be in the /.metadata/.plugins directory so I tried copying groups of plugin data directories across. I found that when I copied over a group of three plugin data directories: org.eclipse.compare org.eclipse.core.resources org.eclipse.core.runtime the Java and CVS Synchronize views both returned to their previous status, without the cvs directories being visible. Looking in the org.eclipse.core.resources directory, there is a subdirectory with a file called .syncinfo, I don't know if that has anything to do with it? Anyway, maybe this extra info will help to fix the problem. Also, I've realised that when I raised this bug I didn't actually explain the impact of the problem. In my original text I've made it sound like it is just a visual annoyance seeing the cvs directories, but it actually stops you from being able to synchronize with your repository, as when you try to do so, you get an error saying something like "a file called projectname/cvs already exists". This means you either have to try and patch up your Eclipse workspace, or take a copy of your files, check everything out from CVS again, then replace those files with the newer versions. OS: IBM OpenClient v1.2 Eclipse Version: 3.2.0 Build id: M20060629-1905
I am not able to reproduce the problem with the steps provided. The team-private marker on resources is stored in the meta-data of the org.eclipse.core.resources plug-in. There are several ways I can think of that may lead to the problem you are seeing: 1) The CVS directories are created externally and, when the refresh occurs, the directory is noticed by a view before the CVS plug-in can mark it as team-private. This could be the cause of what you saw in comment 2. If this was the problem, you can correct it by first ensuring that CVS is loaded (by opening the Repo view for instance) and then restarting Eclipse. 2) The resources meta-data is lost. If this were the case, there should be an accompanying error in the Error log file. Are there any errors in your log that look related (they would have at least some classes from the org.eclipse.core.resources plug-in)?
I'm still getting this problem when I hit refresh. The error in my .log is: !MESSAGE Errors saving CVS synchronization information to disk. Please fix the problems listed below and then update the affected resources from the CVS repository. !SUBENTRY 2 org.eclipse.core.resources 4 272 2007-01-31 00:50:10.673 !MESSAGE A resource already exists on disk /shared/eclipse_testing2/stuff2/Reflections/CVS. !STACK 1 org.eclipse.core.internal.resources.ResourceException: A resource already exists on disk /shared/eclipse_testing2/stuff2/Reflections/CVS. at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:45) at org.eclipse.core.internal.resources.Folder.create(Folder.java:88) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter$1.run(SyncFileWriter.java:439) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.createCVSSubdirectory(SyncFileWriter.java:435) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.writeAllResourceSync(SyncFileWriter.java:148) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.commitCache(EclipseSynchronizer.java:1013) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer$1.run(EclipseSynchronizer.java:517) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.flush(EclipseSynchronizer.java:515) at org.eclipse.team.internal.core.subscribers.BatchingLock$ThreadInfo.flush(BatchingLock.java:174) at org.eclipse.team.internal.ccvs.core.syncinfo.ReentrantLock$CVSThreadInfo.flush(ReentrantLock.java:53) at org.eclipse.team.internal.core.subscribers.BatchingLock$ThreadInfo.popRule(BatchingLock.java:106) at org.eclipse.team.internal.core.subscribers.BatchingLock.release(BatchingLock.java:301) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.endBatching(EclipseSynchronizer.java:499) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.run(EclipseSynchronizer.java:1458) at org.eclipse.team.internal.ccvs.core.resources.EclipseResource$2.run(EclipseResource.java:260) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at org.eclipse.team.internal.ccvs.core.resources.EclipseResource.run(EclipseResource.java:257) at org.eclipse.team.internal.ccvs.core.util.BuildCleanupListener.resourceChanged(BuildCleanupListener.java:141) at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:280) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:274) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) at org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:240) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:146) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Here's the code snippet where the error comes from: if (! cvsSubDir.exists()) { cvsSubDir.create(IResource.TEAM_PRIVATE, true /*make local*/, null); } This is in a workspace runnable which holds a lock on the folder so it should not a race condition. Hence, it would appear that somehow the folder in question exists on disk but not in the workspace. This could easily be the case if you were using an external CVS client but should not happen with the steps you provided. John, do you have any insight here? Hedley, is there anything special about your project setup? Do you use external tools on the project? Do you use resource links?
My workspace is stored on the FAT 32 partition that I share between Windows and Linux. I have found that the problem doesn't seem to occur if I create a workspace on my Linux ext3 filesystem. However, I'd very much like to keep using the FAT32 partition, as, like most users of a dual boot system, I try to store all of my data there so that I can access it from both Windows and Linux. So, is it perhaps something to do with the filesystem / file permissions that is causing the problem? I think that a CVS checkout usually tries to set various file permissions on the files it has checked out, doesn't it? My FAT 32 partition is mounted as: /dev/hda5 on /shared type vfat (rw,uid=500,gid=502,umask=000)
Do you share the workspace project between Windows and Linux as well? That is, do you use the same project on disk in two different workspaces, one on Windows and one on Linux)?
Yes, I use the same workspace on Windows and Linux. Although the problem sounds like it to do with trying to use a FAT32 workspace on a Linux machine, correct? (Since the problem occurs when I create a new workspace. i.e. I don't have to reboot into Windows and use Eclipse from Windows to recreate the problem.)
I was just wondering if you'd made any progress on this? Is the problem caused by the CVS checkout trying to change the file permissions? Or something else?
No, I haven't had time to investigate this further and it is unlikely that I will have time to do so in the foreseeable future. One of the main roadblocks is that I do not have access to a setup that is similar to yours. If you are willing to investigate this further than I will offer whatever assistance I can.
I'm happy to collect information from my system or try out a few things if you want. What is it best to start with? Are there some log files that I can send to you? Or is there some kind of config change you think it might be worth trying?
Actually, there really isn't any tracing that I know of that will help in this situation. One thing I just did is modify the SyncFileWriter to behave better in the case I outlined in comment 5. This change will be available in M6. If you could try that when it becomes available (end of next week) that would be helpful. I should point out that we have seen similar problems involving network drives. There seems to be some instability in the timestamps that get returned from the file system which causes resources to become out-of-sync and appear as dirty w.r.t CVS. We'll see if the change I have made helps out and then go from there.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
