Community
Participate
Working Groups
I don't know whose bug this is, so the lucky core team gets it. :-) In previous builds (last week) as well as I20020411 on Linux, I frequently get in a state where saving a file in an editor reports that the file has changed on disk, prompting me to either load the changes or discard them. This is not repeatable, but happens pseudo-randomly. Most recently, I: 1. Unpacked I20020411 2. Started workbench and loaded some projects from the repository. 3. Opened a Java file, changed one line, and saved it. I got the error. 4. Opened another Java file, changed one line, and saved it. Got the error again. 5. Try other files, could not get the error. 6. Repeated steps 1-4 again, could not get the error. I've seen it at different times, but always while saving a file in an editor.
Do you know which VM you were using when you got this problem?
On linux. > java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010502 (JIT enabled: jitc))
Comments from Bug 13721 ----------------------- We seem to be experiencing a few inexplicable occurances of resources being out of sync with the file system. I've seen nothing in common with these. So far: - SteveN was working against a Novell network drive and had a modified file that he wanted to commit become out of date - James just today working on Linux couldn't save files from the Java editor because of it. When he told me and I went to his office, we couldn't reproduce it. Oddly, it allowed him to open the editor without complaining, but warned on save. - Now this posting below. Odd that two were involving network drives but one was Linux. "AH" <Adalbert.Homa@metavante.com> wrote in message news:a977ve$8rt$1@rogue.oti.com... > "The project was not built since it is inconsistent. > Ensure no other tool is browsing the output directory, > then try refreshing this project and rebuilding it." > > I am getting this error quite often, and I don't know what to do. > I refresh the whole project and try to build, rebuild again but no luck. > I get this error even if I change the output directory to a new directory. > The project is on a network drive (using Samba and ClearCase). > > Maybe related to this, I am having problem with search function. > I try to search for a word in a files (Edit | Search (Ctrl-H)) and > it stops complaining that somebody changed the file. > > I can understand that Eclipse that is trying to watch changes, but > > Help !!! >
*** Bug 13721 has been marked as a duplicate of this bug. ***
Michael believes he has a reproducible case, as follows: - install eclipse on a network drive - check out a project - modify a file in that project, don't save - do Compare With -> Latest from Repo... on that file - Go back to the editor for the file, try to save -> Reports out of sync on the file.
This is reproducible for me with Michael's steps. I bumped up to P1 because if you say "Yes" when it asks if you want to save, it deletes the file and work is lost.
As I suspected, it's completely unrelated to the file being in sync. FileSystemStore.write deletes files when it fails to write. On Novell, it seems that you get a FileNotFoundException when attempting to open an output stream on a file that has been left open by somebody else. Team team was leaving the file handle open after the compare operation, hence we hit this problem. try { String path = target.getAbsolutePath(); writeFolder(new File(target.getParent())); transferStreams(content, createStream(target, append), path, monitor); } catch (CoreException e) { //if we failed to write, try to cleanup the half written file if (!target.isDirectory()) target.delete(); throw e; }
Actually, we weren't deleting the file. During setContents, we *move* the existing file to the local history store, then write the new contents in its place. If the write fails, it appears that the file has disappeared because it has actually been moved elsewhere. We are now *copying* the file to the history store. Then if write fails, the old file is left intact. This might have a slight performance hit (copying is much slower than moving), but we see no other approach that would be resilient in the case of errors. We can't move the old file to the history store, then move it back on failure, because the history store doesn't guarantee that it will retain the file if user policy settings don't permit it. (eg, if it's larger than the specified maximum size).
Is this going to fix the building symptoms in Bug 13721? I have a major problem with this in F1. It is related to building rather than saving resources.
This bug was closed in April so I doubt it will fix a problem you see in F1.
what is your setup? (os, etc) do you have re-producable steps? if so, please re-open.
I had it in M5 as well. I was hoping F1 would fix it but it is not in the release notes so I'm assuming it doesn't contain the fix. My concern is that the reported problem with building will not be not addressed. I am using 2 environments both with F1. Both give the same problems: Nt 4.0: entire Eclipse project is in Clearcase (using a dynamic view). Clearcase symbolic links are used to map the source and dependent jars into the project directory. Since the whole project is in the Clearcase view, the build output directory is of course managed by Clearcase. Solaris/motif: Eclipse project is outside of clearcase. Symbolic links are used to map the source from the clearcase view into my eclipse project. The build output does not go to a Clearcase managed directory.
Eclipse users should use the ClearCase team provider to manage resources which reside in a ClearCase repository. Otherwise (as you have experienced) you will find seemingly random cases where the resources are out of sync with the file system. There is an auto-refresh plugin available from the Platform/Core team web page on dev.eclipse.org (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout% 7E/platform-core-home/dev.html) which automatically tries to refresh resources. But the right answer is to use the team provider plugin.
There is nothing random about this. I cannot get it to build. This includes deleting the bin and refreshing the project. I have also tried deleting the project and importing it again. I have installed the clearcase plugin from the Rational XDE and that does not solve the problem. I get the same error mentioned in duplicate Bug 13721. > "The project was not built since it is inconsistent. > Ensure no other tool is browsing the output directory, > then try refreshing this project and rebuilding it." As for reopening this bug. That depends on whether it is supposed to be fixed in F1. It isn't mentioned in the release notes.
Please enter a new bug report; the situation you are describing seems different from the one addressed in this bug. A fix for this particular bug was released for the M6 milestone. However, there could very well be other reasons why your project isn't in a consistent state. Copy/paste your recent comments into a new report. If you can, give simple steps that reproduce the problem.
Ok raised Bug 17647 However, the identical problem was reported in Bug 13721 which was then closed as a duplicate of this.
