Community
Participate
Working Groups
Build Identifier: 20100917-0705 I am getting following error: The project was not built due to "Resource already exists on disk: '/source/out/com/alerts/COMIFL~1.XML'.". Fix the problem, then try refreshing this project and building it since it may be inconsistent ---------------------------------------------------------------- Earlier evrythng was fine...but all of sudden...it started giving this problem...due to this I m unable to build the project. JRE: jdk1.5.0_22 Reproducible: Always Steps to Reproduce: 1.Clean the project or build 2. 3.
Does a refresh help? What is the "/source/out" folder? Is it the output folder?
refresh didnt help /source/out..is the iutput folder...where class files are created after successfull build
(In reply to comment #1) > Does a refresh help? What is the "/source/out" folder? Is it the output folder? refresh didnt help /source/out..is the iutput folder...where class files are created after successfull build
Can you provide the .classpath file and let me know which classpath entry the particular file is coming from? Can you also check if the file gets deleted when you do a 'clean'?
I'm experiencing this problem with a DTD file with Eclipse 4.2, too. I'm still investingating to understand if the problem is due to some project configuration/build file or if there's a problem in Juno, since I never had such problems with Indigo. I noticed the problem always happen with files that should just be copied to the output folder. I'm going to provide the information requested by Jayaprakash.
Created attachment 222100 [details] .classpath file Here is my .classpath file. The file for which I get the "Resource already exists on disk" is src/log4j.dtd, so it's coming from the first classpathentry.
If I do a "Clean" on the project, unchecking "Start a build immediately after" and removing the "Build automatically" flag, I can see that many files are NOT deleted from build/classes, which is the output dir. However, some of them are.... I don't see any error in the error log when I clean, while when I invoke "Build project" I get this: eclipse.buildId=I20120608-1400 java.version=1.7.0 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=it_IT Command-line arguments: -os win32 -ws win32 -arch x86_64 -debug -consoleLog Error Wed Oct 10 09:20:46 CEST 2012 JavaBuilder handling ImageBuilderInternalException while building: UtopicMusicServer org.eclipse.core.internal.resources.ResourceException: Resource already exists on disk: '/MyProject/build/classes/log4j.dtd'. at org.eclipse.core.internal.localstore.FileSystemResourceManager.copy(FileSystemResourceManager.java:306) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:566) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.copyResource(AbstractImageBuilder.java:408) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder$3.visit(BatchImageBuilder.java:240) at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:95) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:52) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.copyExtraResourcesBack(BatchImageBuilder.java:199) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:121) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:48) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:513) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:432) at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:305) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) I must manually delete files on the disk in order to repair the situation. Please note it must not be a folder permission problem, since I'm using a "public" folder for the wprkspace.
Thanks for sharing the classpath file. Looking the stacktrace and code, the resources in the output location must have been deleted inside BatchImageBuilder#cleanOutputFolders(). But apparently the delete wasn't successful. Is there a chance that the log4j DTD was used by another process and hence couldn't be deleted?
(In reply to comment #7) > If I do a "Clean" on the project, unchecking "Start a build immediately > after" and removing the "Build automatically" flag, I can see that many > files are NOT deleted from build/classes, which is the output dir. However, > some of them are.... I tried it with a project with a similar classpath as given and I noticed the same behavior. When doing a clean with both the build automatically options turned off, I do see the DTD file present in the output folder. However, once I turn on the "Build Automatically", the DTD and all other files are removed and they are copied over again as part of build.
Hi Jayaprakash, isn't it strange that the clean operation doesn't delete files in the output folder when both the build automatically options are turned off? Anyway, as I said, in my case I saw that only SOME of the files were not deleted. In any case, I did that test with both the build automatically options turned off just to investigate. In the normal use case, I have the "Build automatically" option in Project menu turned on and sometimes it happens that I still see this problem. It doesn't happen always, but it did at least 3-4 times from when I upgraded to Juno. The DTD and the other files that are not deleted must not be locked by another process: there's no process running on those files when I try to re-build and I can easily delete files from the outside (with a file manager application). If there were another process, I couldn't delete them even with am external file manager application.
(In reply to comment #10) > Hi Jayaprakash, > isn't it strange that the clean operation doesn't delete files in the output > folder when both the build automatically options are turned off? My bad. The method cleanOutputFolders() does get called even during the "clean" operation. So, you are right. We do get two chances to delete the files in the output location. I will try to find out what's going when I do a "clean". > If there were another process, I couldn't delete them even with am external > file manager application. That's correct. Do you see any patterns in the occurrence of errors, or the files that have this problem? Is it always the same file(s) or of the same kind ?
(In reply to comment #11) > That's correct. Do you see any patterns in the occurrence of errors, or the > files that have this problem? Is it always the same file(s) or of the same > kind ? That's hard to answer this question. What I see is that it happens on static resources (dtds, properties, etc.). Today it happened again, but on a .properties file, coming from the same classpath entry.
Hi Jayaprakash, I've some more info on how this problem is produced. I have an Ant script that I run to jar the output produced by Eclipse in build/classes output folder into an archive I place on another folder (not managed by Eclipse). Then I start Tomcat on this other folder. That is, this script is just READING contents in build/classes. The workflow is usually this: 1. I change a class and hit Ctrl+S 2. build automatically is on, so this class is compiled and put in build/classes; all works fine 3. I run the Ant script to jar the contents of build/classes into a JAR file contained into a folder which is not managed by Eclipse and run Tomcat on that folder 4. I repeat steps 1-2: all works fine 5. I repeat again the steps 1-2: the build error is produced That is, every other change after running the Ant script produces the error. Strange thing: I'm not changing static resources, however the error message says "resource already exists" always for static resources. Another strange thing: the error is given after the SECOND change+save on the class file. The first one works ok. Again: I'm 100% sure files are not locked at OS level, since I can delete them manually using Explorer. Also, Tomcat is not reading/taking files from build/classes. Lastly, if at step 3 I stop Tomcat right after it has started, then proceed with steps 4 and 5, the problem happens all the same. These are three clues that it must not be a problem related to Tomcat locking files. Is it possible that the JAR command issued by Ant "touches" the files in build/classes in a way that interferes with Eclipse build process? If so, why should this annoy Eclipse?
(In reply to comment #13) > Hi Jayaprakash, > I've some more info on how this problem is produced. Thanks for that! > Is it possible that the JAR command issued by Ant "touches" the files in > build/classes in a way that interferes with Eclipse build process? If so, > why should this annoy Eclipse? How is the Ant script run? From eclipse or outside eclipse?
The script is run from Eclipse via External Tools configuration. Build before launch => build the project containing the selected resource, include referenced projects. Refresh resources upon completion => the project containing the selected resource, recursively include sub-folders. The following targets are executed: - stop Tomcat (if running) - refreshServer - wait (waits 5 seconds) - start Tomcat Refresh server does the following: <target name="refreshServer" depends="cleanClassesDir, compile, refreshClientWebResources"> <jar destfile="${warDir}/webapp/WEB-INF/lib/UtopicMusicServer.jar"> <fileset dir="${classesDir}" /> </jar> <copy todir="${warDir}/webapp"> <fileset dir="WebContent" /> </copy> <copy todir="${warDir}/webapp" overwrite="true"> <fileset dir="configs/devel-local" excludes="**/*_example* **/README"> </fileset> </copy> </target> Where: ${warDir} is a folder in my project which is filtered out from the navigation views using resource filters, hence it's not handled by Eclipse ${classesDir} is build/classes Tomcat is then run over ${warDir}. Please note that the dependsOn targets "cleanClasses" and "compile" are actually not executed, because they all have unless="dont.recompile.server", which is a property currently set that avoids cleaning and recompiling (I want to use the output produced by Eclipse, I don't want to recompile all from scratch; but the script is designed to be used even without Eclipse running). I'm sure that "cleanClasses" and "compile" are not executed and simply skipped. Instead, refreshClientWebResources is a task that simply calls another Ant scripts that copies some more resources to ${warDir} coming from another project (so it doesn't even read from build/classes).
(In reply to comment #15) > The script is run from Eclipse via External Tools configuration. Thanks for the painstaking detail. Unfortunately, despite my best effort to repeat your steps, I just can't reproduce the bug. I can recompile the class even when tomcat is running. At this point, the only way I can think of is to put a JDT/Core bundle with some trouble-shooting code in your environment and that will give us some idea as to what's going on with the builder, esp. when resources are being deleted from the output location. This week we are busy with the M3 testing. I will provide you the modified JDT/Core bundle next week that you can put in your environment and share the log files.
Hi Jayaprakash, thanks for your support. No problem for me to try your modified bundles. Let me know!
Just another detail. When you reach step 5 in my previous directions, you won't get the build error ("The project was not built due to...") explicitly: however, the project the edited file (let's say it's project P) and another project that depends on the first (le'ts say it's project Q) both complain that some classes from project P are not found. The strange thing is that those classes were not the ones I changed, so I wouldn't expect them to be recompiled by the incremental builder. Anyway, when I get to these weird compilation problems, I usually clean the offending project (P). If I do this, then the explicit error ("The project was not built due to...") is produced and the ResourceException error is printed in the Error Log (see my stacktrace reported in comment #7).
Hi Jayaprakash, did you have a change to look at this recently?
Created attachment 223820 [details] Plugin patch Hi Mauro, As I said earlier, let's try the attached JDT/Core plugin in your environment. I have added more debug statements. Try downloading the eclipse version I20121113-0800 and replace the existing jdt.core plugin with the one attached here. Also enable the following debug option in your environment: org.eclipse.jdt.core/debug/builder=true And please share the log file when the error happens again. If you have any question on enabling the tracing, you can refer to this page: http://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F
Hi Jayaprakash, I did the following: 1) downloaded Eclipse Runtime Platform from http://download.eclipse.org/eclipse/downloads/drops4/I20121113-0800/ 2) unzipped and started the Runtime Platform 3) installed the CVS client plugin and JDT plugin from the ZIP files downloaded from http://download.eclipse.org/eclipse/downloads/drops4/I20121113-0800/ 4) installed WTP, PDT, Mylyn from the Kepler update site provided with the Runtime Platform 5) installed the other relevant plugins (like Google Plugin for Eclipse and Groovy) from the previous Eclipse installation (using Import | Install | From existing installation) 6) created a .options file in Eclipse dir with: org.eclipse.jdt.core/debug/builder=true 7) ddded the following to Eclipse.ini: -debug -consoleLog -vm C:/Program Files/Java/jre7/bin/javaw.exe 8) opened Eclipse on the previous workspace After a bit of cleanup I then did the following: 1) closed Eclipse 2) went with Windows Explorer to <workspace>\UtopicMusicServer (the project that has problems) and delete all files from build\classes (the output folder) 3) started Eclipse 4) issued a "Clean..." on all the projects 5) waiting for "Building workspace" to terminate 6) made a change to a file and saved => no problems 7) run the Ant task to copy files and run Tomcat 8) stopped Tomcat 9) made a change to the same file and saved => the UtopicMusicClient (another project that depends on UtopicMusicServer) shows a build path error, but UtopicMusicServer does not: it only shows a Groovy compilation error 10) issued a "Clean..." for ONLY the UtopicMusicServer project 11) BOOM => the build path error on UtopicMusicServer arises because "Resource already exists..." I'm attaching the produced log, although it doesn't seem to contain much information. I see a lot of "!--- cannot resolve..." but I'm pretty sure the were printed on startup (maybe because of step 2) which deleted files without letting Eclipse know). When the problem occurs (or immediately after) there seems to be no particular logging output.
Created attachment 223842 [details] Produced log on 2012-11-22
Created attachment 223843 [details] Full log of 2012-11-12 after repeating steps I did the following: 1) WITHOUT restarting Eclipse, I deleted the contents of UtopicMusicServer\build\classes with Windows Explorer 2) issued a Clean... on the UtopicMusicServer only 3) build path errors went away 4) then, I repeated steps 5)-11) of the previous comment The resulting log is attached (the first lines are obviously the same of the previous attached log, since I didn't restart Eclipse). As you can see, nothing more than before. Again, the "!-- cannot resolve" entries were printed on the first Clean operation (after I manually deleted contents in build\classes), but no additional output was printed when (or immediately before) the real problem happens.
Please note that at step 9) of comment 21 the Groovy compiler complains it can't resolve a Java class file and produces a "Java" error on the UtopicMusicServer project, but, as I said, no build path error on UtopicMusicServer is reported by Eclipse. However, as I said, a build path error on UtopicMusicClient (which depends on UtopicMusicServer) is indeed produced: I don't see the red "!" icon used for build path problems on UtopicMusicClient project in Package Explorer, but rather a simple red mark; however, in the Markers view I see it as a build path error that says that "the project cannot be built because its build path is incomplete - cannot resolve <another Java class in UtopicMusicServer>. Please correct error first etc. etc.". So, something is broken already at step 9), but the problem is shown in its entirety only when I issue a Clean... on UtopicMusicServer project (step 10) of comment 21).
(In reply to comment #21) > Hi Jayaprakash, > I did the following: Did you copy the jdt/core plugin I attached in comment #20 into the eclipse installation? Did I miss something?
Yes, sorry, I forgot to say. Of course, after installing JDT, I replaced the org.eclipse.jdt.core_3.9.0.v20121109-093838.jar with the one attached here. I suppose the entries starting with "!--" in the log files are the one produced by your patched JAR, aren't they?
(In reply to comment #26) > Yes, sorry, I forgot to say. Of course, after installing JDT, I replaced the > org.eclipse.jdt.core_3.9.0.v20121109-093838.jar with the one attached here. > I suppose the entries starting with "!--" in the log files are the one > produced by your patched JAR, aren't they? No, they were already there, just get printed since we enabled tracing. Interestingly, I don't see the logs I was expecting. I see multiple src entries in the classpath. Can you try this small experiment and let me know what happens - assuming the troublesome file is in the "src" entry, could you remove the other source entries from the classpath and see if there is still a problem? TIA!
Hi Jayaprakash, I just tried to remove the other source entry (there are two: the one containing the troublesome file and another; I removed the latter) but I see no changes in behaviour, i.e.: I still see the "Resource already exists on disk" error when trying steps from comment 13 and then I clean the server project. There's only one thing to correct: it's not true that the error always shows after the second change, as I said. During my experiments (independently from the fact I Removed the second source folder from the build path or not) I saw that it can happen even after the first change. So, I'm still puzzled.
Hi Jayaprakash, any idea on how to proceed on this?
(In reply to comment #29) > Hi Jayaprakash, > any idea on how to proceed on this? Honestly, I don't know what's going on. Perhaps we should try to setup a remote debugging session if that works for you?
Hi Jayaprakash, it's ok for me to setup a remote debugging session, but please consider I've never done it, so please, let me know exactly what to do. I imagine that we have to fix a date/time to meet online and that I'll have to open a port on my router to my working PC. We can arrange via e-mail if it's ok for you.
This bug is 3 years old and still not solved. I have to say, this bug is also in all following versions, current one included. We can setup workarround to exclude build for non java files, but it prevents me to run JUnit tests which needs those file. It is bothering me for years now. I really wish this bug is solved as soon as possible.
(In reply to Martin Soltis from comment #32) > This bug is 3 years old and still not solved. > I have to say, this bug is also in all following versions, current one > included. > We can setup workarround to exclude build for non java files, but it > prevents me to run JUnit tests which needs those file. It is bothering me > for years now. I really wish this bug is solved as soon as possible. Sorry to hear about your situation. For the last year and half, we have been very busy with Java 8 work - Java 8 has been described as arguably the biggest change to Java in its history by the language architects leading the design and evolution of the language This has complained overbooked our resources. Setting the target to 4.4, so this will be on the radar.
Created attachment 239545 [details] ProcessExplorer shows that eclipse is using the file that cannot be deleted. I uses STS built on Eclipse 3.8.2 I have attached ProcessExplorerScreenshot.png that shows that Eclipse is holding a the file open and therefore it cannot delete it. Very strange it does not happen with any other files.
(In reply to Balázs Palcsó from comment #34) > Created attachment 239545 [details] > ProcessExplorer shows that eclipse is using the file that cannot be deleted. > > I uses STS built on Eclipse 3.8.2 > I have attached ProcessExplorerScreenshot.png that shows that Eclipse is > holding a the file open and therefore it cannot delete it. Very strange it > does not happen with any other files. To add to the above: - I can delete all the files in the build dir manually outside Eclipse, except persistence.xml - Refresh and then Project -> Clean does not work, unless I restart Eclipse. And this always affects me I mean comes back after each non-incremental build or when persistence.xml is changed.
I've also been having this problem for some time now. We also use a OneJAR approach that builds everything into a single jar file using an ant script, but I have an xsl file on the classpath that generates this error every other clean/save/etc. The exclusion workaround also doesn't work for me either because of JUnit tests.
We are having a similar problem - see bug 403170. The "Include Only" Resource filter seems to be the culprit in that case and may also be the problem here. (I don't yet know why, though.) Try removing these filters and see if the problem still occurs. I suspect that the filter causes the other, non-included resources to be handled differently by Eclipse, which breaks certain operations.
Is there any process on this bug? I run into the same issue today: The project was not built due to "Resource already exists on disk: '/some.project/bin/.DS_Store'.". Fix the problem, then try refreshing this project and building it since it may be inconsistent ".DS_Store" is a Mac OS specific file. This should be completely ignored in the first place (is there a setting to ignore these files?). Using - Java 8 - Eclipse Neon - running on Mac OS
(In reply to Jens von Pilgrim from comment #38) > Is there any process on this bug? Please ask again when Java 9 has sailed :)
I got the same error. The only thing I did, was to copy the project folder in order to backup it... I am using Mac OS and Java 8
Hi, I got the same error. Here are the steps that I followed, which fixed that error. 1. Uncheck 'Build Automatically'. 2. Click Clean solution 3. Ensure 'Start a Build Immediately' is UNCHECKED. 4. Perform the clean 5. Run it to build It gets Build without any issues of "Resource already exists on disk: ,..." But, after clean, it doesn't remove anything in bin folder
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.
This problem still occurs: - Eclipse Version: 2022-03 (4.23.0), Build id: 20220310-1457 - Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components) - no additional plugins or - Windows 10 Pro for Workstations, Version 10.0.19044 Build 19044 - Dell Precision Tower 3431, Intel Xeon E-2224 CPU @ 3.40GHz - D: drive has development folders and Tomcat instance Setup: 1. Create a Git project (e.g., "myapp": Maven, WAR, Tomcat 8.5, Java 8 (1.8.0.101) 2. Folders: - /src/main/webapp (1,288 files) : *.jsp = 611 files; 3 levels deep : *.htm = 34 files; 1 level deep : *.js = 36 files; 2 level deep : images = 571 files; 3 levels deep : other files = 36 files - /src/main/java (154 files; 5 level deep) - /src/main/resources (8 files) - /src/main/web-resources (288 files; *.jasper; 3 levels deep) - /src/test/java (230 files; 5 levels deep) 3. pom.xml 4. Servers (Eclipse logical servers) - 1 instance: Apache Tomcat 8.5 (physical = 8.5.55) Steps: . DISABLE Project > Build Automatically . (project context menu) > Maven > Update Project... (use defaults) . Run Maven: Goals: compile . Project > Clean . Project > Build All Error: Eclipse complains about the existence of a file in the Maven staging area '/target/"myapp"/SomeFile.jsp' Notes: 1. The error tends to occur when the project is new or newly imported from Git, or maybe it's when Eclipse is freshly started, or maybe "eclipse -clean -clearPersistedState". 2. The error can be "cleared" by some combination of enable/disable "Build Automatically", Project Clean, Maven Clean, Build All, etc. 3. Once the error is somehow "cleared", it's difficult to get it to occur again.
Created attachment 288576 [details] Comment 43 Eclipse Full Configuration (This is the full configuration for Comment 43)
