Community
Participate
Working Groups
The following incident was reported via the automated error reporting: code: 4 plugin: org.eclipse.jdt.core_3.11.0.v20150317-0048 message: JavaBuilder handling CoreException fingerprint: 3b4766ff exception class: org.eclipse.core.runtime.CoreException exception message: File not found: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class. number of children: 1 org.eclipse.core.runtime.CoreException: File not found: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class. at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:49) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:391) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:834) at org.eclipse.core.internal.resources.File.getContents(File.java:269) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsByteArray(Util.java:1135) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:889) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileContents(IncrementalImageBuilder.java:831) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:859) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:190) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:531) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:453) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:367) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:330) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:304) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:135) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:267) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:195) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) caused by: java.io.FileNotFoundException: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class (No such file or directory) at java.io.FileInputStream.open0(FileInputStream.java:-2) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:382) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:834) at org.eclipse.core.internal.resources.File.getContents(File.java:269) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsByteArray(Util.java:1135) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:889) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileContents(IncrementalImageBuilder.java:831) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:859) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:190) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:531) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:453) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:367) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:330) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:304) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:135) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:267) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:195) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) --- code: 271 plugin: org.eclipse.core.filesystem_1.5.0.v20150313-1707 message: File not found: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class. fingerprint: 55a66eea exception class: java.io.FileNotFoundException exception message: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class (No such file or directory) number of children: 0 java.io.FileNotFoundException: /home/rtack/dev/projects/albit/m2m_flex/server/target/classes/com/albisengineering/m2m/flex/Application.class (No such file or directory) at java.io.FileInputStream.open0(FileInputStream.java:-2) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:382) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:834) at org.eclipse.core.internal.resources.File.getContents(File.java:269) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsByteArray(Util.java:1135) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:889) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileContents(IncrementalImageBuilder.java:831) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:859) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:190) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:531) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:453) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:367) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:330) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:304) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:135) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:267) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:195) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) General Information: reported-by: Raphael Ackermann anonymous-id: 4bfd38ea-fb4e-4a28-8e0d-854e16701007 eclipse-build-id: 4.5.0.I20150320-0800 eclipse-product: org.eclipse.platform.ide operating system: Linux 3.16.0 (x86_64) - gtk jre-version: 1.8.0_40-b25 The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.filesystem_1.5.0.v20150313-1707 2. org.eclipse.core.jobs_3.7.0.v20150316-1238 3. org.eclipse.core.resources_3.9.100.v20150313-1707 4. org.eclipse.core.runtime_3.11.0.v20150316-1241 5. org.eclipse.jdt_3.11.0.v20150320-0800 6. org.eclipse.jdt.core_3.11.0.v20150317-0048 Please note that: * Messages, stacktraces, and nested status objects may be shortened. * Bug fields like status, resolution, and whiteboard are sent back to reporters. * The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality. Other Resources: * Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/55191b89e4b026254edff0ad * Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide Thank you for your assistance. Your friendly error-reports-inbox.
It would be good to have the steps for this. Is the class being mentioned (Application.class) present in the given location?
I got that more ore less reproducible I think. This file was likely removed by an external build with Maven. Maven run before with maven clean install, i.e., it removed all files from the output folder. But it also produces new files at that location. Is Eclipse keeping the reference on the old file and thus fails?
(In reply to Marcel Bruch from comment #2) > I got that more ore less reproducible I think. > > > This file was likely removed by an external build with Maven. Maven run > before with maven clean install, i.e., it removed all files from the output > folder. > > But it also produces new files at that location. Is Eclipse keeping the > reference on the old file and thus fails? Assuming maven writes the files to the same location, it probably happens because JDT assumes the class files are already present but the workspace has not been refreshed a result of which file.exists() returns true.
(In reply to Jay Arthanareeswaran from comment #3) > Assuming maven writes the files to the same location This is true. The output location of Maven is the same.
Happened to me right after a git checkout from the command line. Switching to a different branch where the file that threw the error had moved.
I just ran a maven build on a webapp inside Eclipse, clean install skipping tests and this was the result.... HTH, Nick
Created attachment 257201 [details] Add robustness to unannounced changes Something like this might help in racy conditions such as this. Unfortunately core.resources doesn't appear to provide much in the way of robustly handling unsynchronized changes in the file system being detected. Here a file existed in the workspace, but the check for whether it still exists and needs to be replaced or doesn't and needs to be created used old information or it became stale before the operation completed. So then it falls on the clients to add robustness around contended workspace locations.
Timo, thanks for the patch. Here's my understanding of the issue, though: 1. First we checked if the files exists before writing. Check returns true. 2. As we proceed to write, we want to check if the file's content has changing. The idea is to skip if the content is same. 3. Now between 1 and 2, someone has removed the file. Now this could mean the entire folder or just the file. If we try to do (2) again in case of this error, it will only help if maven or whoever is colliding is done with their work by this time, right? In this particular case, we might simply want to dump the content if the error is of kind FNFE. Let me know if I am missing something. And as you called out, if two people are trying to write to the same file, we currently don't have the infrastructure to handle/notify better.
(In reply to comment #8) > Timo, thanks for the patch. Here's my understanding of the issue, though: > > 1. First we checked if the files exists before writing. Check returns true. > > 2. As we proceed to write, we want to check if the file's content has changing. > The idea is to skip if the content is same. 1. Yes. 2. Yes. > 3. Now between 1 and 2, someone has removed the file. Now this could mean the > entire folder or just the file. Yes to both. We would try to create the missing parent folders at this point but since we think the file is still present that step is skipped. > If we try to do (2) again in case of this error, it will only help if maven or > whoever is colliding is done with their work by this time, right? In principle, yes, but this is by necessity limited to what we know about the culprit and the kind of work it's doing. Which isn't much. Luckily for us, to complete our task we don't need that much. We only need the state of the file to remain consistent between the workspace and the file system until we are done, and a parent folder we can write to to start from. With them we are back at the same square one we started this run from earlier. > In this particular case, we might simply want to dump the content if the error > is of kind FNFE. Let me know if I am missing something. I think this would cause a dependent project waiting next in line to fail its build. If the error ends up categorized as a classpath problem then most likely the build will grind to a halt soon and will need manual cleaning to get it going again. > And as you called out, if two people are trying to write to the same file, we > currently don't have the infrastructure to handle/notify better. In this case we have the contents of our version in a neat byte[] array and we can trust the integrity of our file, so we could just keep trying and trying until it gets through :)
bulk move out of 4.8
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. -- The automated Eclipse Genie.
