Comment 1 Gunnar Wagenknecht 2010-12-15 04:40:50 EST

Note, it seems that mostly folders are the 'files' that couldn't be deleted. I wonder if there is also a timing issue involved.

Comment 2 Olivier Thomann 2010-12-16 09:16:23 EST

Ayushman, could you please investigate how we can have file handle leaks to files inside the output folder ?
Thanks.

Comment 3 Stephan Herrmann 2010-12-16 10:07:11 EST

(In reply to comment #2)
> Ayushman, could you please investigate how we can have file handle leaks to
> files inside the output folder ?
> Thanks.

If it is an issue of file handle leaks, maybe this is related:
I recently started to have difficulties launching JUnit plugin tests
where many NoClassDefFoundErrors where thrown, with detail message:
no more file handles (running on Linux).

In my case it usually helps to switch from JDK 1.6.0.22 back to 1.6.0.16.
Maybe the JDK is keeping file handles where it shouldn't?
Just a wild guess..

Comment 4 Michael Vorburger 2011-06-09 06:19:25 EDT

This is affecting us too - any chance this will get looked at in the foreseeable future?

Comment 5 Kai Kreuzer 2011-06-09 06:36:29 EDT

FYI, we experience the same issue on Eclipse 3.6.2, so it was most likely introduced directly after 3.6.1.

I am not sure about it, but I have the impression that it could not be related to JDT, but to m2e, because it's usually Maven-enabled projects where this occurs.

@Gunnar: Are you using m2e as well? This would be some indicator for my theory - if so, this issue should maybe moved over from JDT to m2e?

Comment 6 Gunnar Wagenknecht 2011-06-09 06:45:59 EDT

(In reply to comment #5)
> @Gunnar: Are you using m2e as well? This would be some indicator for my theory
> - if so, this issue should maybe moved over from JDT to m2e?

I don't have m2e installed but I still get the issue occasionally.

FWIW, I suspect that it might be related to a new hard drive. It's a Seagate Hybrid drive (500GB with 4GB SSD cache). For some reason I've been seeing this issue more often since I switched to that drive. It looks like a timing issue. Usually just a manual refresh of the project is necessary and then it builds fine again.

Comment 7 Alain Picard 2011-07-20 09:50:24 EDT

I have been having this issue for quite some time (3.6.1 timeframe makes sense) and I'm the only one on my team to experience this.

I don't use Maven so that pretty much clears that up, but I use an SSD drive and I have the feeling that this is indeed a timing issue.

Comment 8 Stephan Herrmann 2011-08-12 12:47:00 EDT

OK, we might not need the JDT to reproduce this bug. Today I performed some
refactoring (moving packages, deleting a project etc.) and saw two instances
of  

   Could not delete '/my.project/my/dir'.


First instance had this call chain:
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.delete(FileSystemResourceManager.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.internalDeleteFolder(ResourceTree.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.standardDeleteFolder(ResourceTree.java:798)
	at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1935)
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:780)
	at org.eclipse.jdt.internal.core.JavaModelOperation.deleteEmptyPackageFragment(JavaModelOperation.java:316)

and more frames within the JDT, but I don't think these are relevant.

--------------------------------

Here's the second stack (from trying to delete a project):


org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.delete(FileSystemResourceManager.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.internalDeleteFolder(ResourceTree.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.internalDeleteProject(ResourceTree.java:387)
	at org.eclipse.core.internal.resources.ResourceTree.standardDeleteProject(ResourceTree.java:837)
	at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1939)
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:780)
	at org.eclipse.core.internal.resources.Project.delete(Project.java:344)
	at org.eclipse.ltk.core.refactoring.resource.DeleteResourceChange.perform(DeleteResourceChange.java:130)
	at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
	at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
	at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Contains: Problems encountered while deleting files.
Contains: Could not delete: D:\workspaces\dodsl20\com.gk_software.core.dsl.domain\src\main\java\com.
Contains: Could not delete: D:\workspaces\dodsl20\com.gk_software.core.dsl.domain\src\main\java.
Contains: Could not delete: D:\workspaces\dodsl20\com.gk_software.core.dsl.domain\src\main.
Contains: Could not delete: D:\workspaces\dodsl20\com.gk_software.core.dsl.domain\src.

Yes, I started the action from the PackageExplorer but the full stack
shows no JDT.

I've never seen this on my linux+SSD box, this happened at work on Windows 7
with a 7200rpm physical disk. Has anybody seen this prior to Windows 7?

Should we move the bug to core.resources?

Comment 9 Stephan Herrmann 2011-08-12 13:26:44 EDT

BTW: the tragic part was: when the error occurred during a rename package
operation I got an error dialog asking "Undo" or "Abort"?
After hitting "Abort" the directory I was moving had vanished from my disk.

Could this be caused by a JDT refactoring? Any idea how aborting a move
can cause total data loss?

The relevant part of the stacktrace (omitted from the previous report) is:

org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:793)
	at org.eclipse.jdt.internal.core.JavaModelOperation.deleteEmptyPackageFragment(JavaModelOperation.java:316)
	at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processPackageFragmentResource(CopyResourceElementsOperation.java:567)
	at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElement(CopyResourceElementsOperation.java:403)
	at org.eclipse.jdt.internal.core.MultiOperation.processElements(MultiOperation.java:163)
	at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElements(CopyResourceElementsOperation.java:417)
	at org.eclipse.jdt.internal.core.MultiOperation.executeOperation(MultiOperation.java:90)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
	at org.eclipse.jdt.internal.core.JavaModel.rename(JavaModel.java:285)
	at org.eclipse.jdt.internal.core.PackageFragment.rename(PackageFragment.java:432)
	at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.renamePackage(RenamePackageChange.java:212)
	at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.doRename(RenamePackageChange.java:139)

Comment 10 Stephan Herrmann 2011-08-12 13:45:07 EDT

Another hypothesis: since I'm using subversive and subversive is known
to have issues with moving/deleting directories (see eg. bug 248284)
if subversive leaves the .svn/ folders in deleted folders, while the JDT
tries to remove the folder: couldn't that explain why deleting fails?
But that should actually be reproduceable...

Sorry, if all this is quite vague, I'm just trying to connect some bits
and pieces of a bug that just killed a good day's work ...

Comment 11 Gunnar Wagenknecht 2011-08-12 14:04:28 EDT

Stephan, I think what you are seeing is different. There are such refactoring issues with projects in SVN (Subversive as well as Subclipse). I think this really has something to do with SSDs as usually just the bin folder is affected.

My recommendation would be to have a configurable option to re-try the failed delete a second time quitly. Only if that fails an error should be reported.

Comment 12 Stephan Herrmann 2011-08-12 20:41:45 EDT

(In reply to comment #11)
> Stephan, I think what you are seeing is different.

Maybe you're right - but how do we know for sure?

> There are such refactoring
> issues with projects in SVN (Subversive as well as Subclipse).

Yea, I tend to seeing this as the root cause for one of my errors.

But is deleting a project intercepted by Subversive? I hope not,
they have no business in that operation. Also the symptoms look very
similar: identical top stack frames plus a list of nested folders
reported as undeleteable (see second stack in comment 8).


> I think this
> really has something to do with SSDs as usually just the bin folder is
> affected.

Could also say: bin is the folder where recursive delete happens most
frequently.

> My recommendation would be to have a configurable option to re-try the failed
> delete a second time quitly. Only if that fails an error should be reported.

Should the retry happen in BatchImageBuilder.cleanOutputFolders()?
Sounds pretty safe to me, though that'd be clearly only a workaround
for some yet unknown root problem.

Comment 13 Missing name 2011-12-19 10:56:35 EST

We have this problem on many workstation,
all using Window 7 32 or 64 bit.
We had no problems with win xp.

Several JVM versions are used:
1.6.0_21
1.6.0_12
1.6.0_29

Using both eclipse 3.7.1 and 3.5.1

We think its some interference with the virus scanner (symantec).

Is there any work going on to solve this?
Perhaps a retry could help.

Thanks.

Comment 14 Missing name 2011-12-19 10:58:06 EST

may be related to: Bug 309235

Comment 15 Ayushman Jain 2011-12-19 11:15:17 EST

*** Bug 309235 has been marked as a duplicate of this bug. ***

Comment 16 Srikanth Sankaran 2011-12-20 00:45:04 EST

Load balancing, Thanks Satyam for offering to take this up.

Comment 17 Missing name 2011-12-21 03:05:08 EST

Seems to be an Windows 7 UAC issue.

Comment 18 Olle Lindberg 2012-05-09 11:36:34 EDT

Been playing around with this error and believe it or not, I think it's related to Windows 7, Navigation pane and explorer.exe file handles.

Let me explain.

When "Navigation pane" is enabled and you navigate to a folder using said pane, explorer.exe has open file handles to this directory *even though you navigate elsewhere*. When "Navigation pane" is off, Windows 7 releases the handle as soon as you leave the directory.

Quick way to reproduce the error. To simplify I'm using cmd.exe to delete the folders but the same thing happens if use "Clean project" from Eclipse.

1: Create c:\a_dir\another_dir\foo.txt
2: Enable the "Navigation pane" and click your way down to c:\a_dir\another_dir.
3: Now navigate away from this folder (but don't close explorer).
4: Recursively delete a_dir from command line: rmdir /q /s c:\a_dir

Result: Error message "The directory is not empty" appears and only another_dir is deleted. Run the command again and c:\a_dir is also removed.

If you do the exact same thing but with the pane disabled, everything goes as expected.

Antivirus on or off does not make a difference. File indexing is disabled.

Does this shed any light on this issue? Does it happen to anyone else?

Comment 19 Olle Lindberg 2012-05-09 11:56:11 EDT

Addition to my comment "If you do the exact same thing but with the pane disabled, everything goes as expected."

After disabling the pane, Explorer must be restarted for the file handles to stop "leaking".

Comment 20 Gunnar Wagenknecht 2012-05-09 13:47:09 EDT

I don't think it's that. Although I'm on Windows 7, I don't use Windows Explorer at all.

Comment 21 James Fry 2012-05-29 06:36:32 EDT

I also get this, on Windows 7 Enterprise 64bit SP1, but I'm running a 32bit JDK and Eclipse build. I also have Symantec Endpoint Protection (not through choice, and I can't disable/remove it). The machine is a Core2 Duo E8400 3.0GHz, with a 120GB Intel 520 SSD. The installation of Windows was fresh not an upgrade.

My Eclipse installation has the following installed (using director):
Checkstyle, CVS, EGit, Help, JDT, JGit, Platform, IDE, PDE, RCP, WST XML, Jadclipse, Findbugs, m2e, Mylin (inc Trac connector), PMD, Workspace Mechanic, and Yourkit.

If I clean the affected projects, the problem invariably goes away, but I get this happening many times a day and it is quite frustrating. It seems to happen most when a lot of code has changed (eg switching branch), but that might just be Eclipse deciding to rebuild a large number of projects (insane build order is another gripe with the plugin builders, but thats for another ticket!)

While I have EGit installed, I do not use it and instead use the command line / gui tools (it is too slow on the huge workspace I have), so I don't think EGit/JGit is involved.

Comment 22 Ed Willink 2012-06-06 10:02:19 EDT

In the past I have had this error many times as a result of re-building while a debugged application is locking a bin/... data file (copied from src/...) that needs to be deleted for the rebuild to happen. Once this happens Eclipse is confused and clean doesn't help. The trick is to exit the debugger, do a dummy edit of a similar data file, the rebuild happens and all the data files are copied across.

Comment 23 Ed Willink 2012-06-06 10:07:51 EDT

Today, I'm having a really really bad day with 4.2RC3. I seem to have an infinite rebuild loop whereby Acceleo generates a Java file that refreshes the workspace and wakes up EGIT for a reindex; so far reasonable, but something then kicks off Acceleo again.

Examination of the problem view shows that the root bin cannot be deleted. The error log shows many more detailed bin folder deletion problems.

org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.delete(FileSystemResourceManager.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.internalDeleteFolder(ResourceTree.java:352)
	at org.eclipse.core.internal.resources.ResourceTree.standardDeleteFolder(ResourceTree.java:798)
	at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1978)
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:804)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:114)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.clean(JavaBuilder.java:291)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:730)
	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.basicBuild(BuildManager.java:256)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:394)
	at org.eclipse.core.internal.resources.Project$1.run(Project.java:618)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597)
	at org.eclipse.core.internal.resources.Project.build(Project.java:114)
	at org.eclipse.ui.internal.ide.dialogs.CleanDialog.doClean(CleanDialog.java:319)
	at org.eclipse.ui.internal.ide.dialogs.CleanDialog$1.runInWorkspace(CleanDialog.java:151)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Contains: Problems encountered while deleting files.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl\examples\build\acceleo.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl\examples\build\fragments.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl\examples\build\utilities.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl\examples\build.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl\examples.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse\ocl.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org\eclipse.
Contains: Could not delete: C:\GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\bin\org. 

(And this is after I restarted Eclipse.)

Comment 24 Ed Willink 2012-06-06 10:37:41 EDT

A significant contributory factor to  my latest problem was that even after exiting Eclipse, Windows Vista could not delete the files with administrative privilege. A reboot and all is ok.

So, something (very very probably an Eclipse thread) was locking the bin tree, and the build process malfunctions very badly if folder deletion malfunctions.

Comment 25 Satyam Kandula 2012-06-07 01:21:34 EDT

(In reply to comment #24)
> A significant contributory factor to  my latest problem was that even after
> exiting Eclipse, Windows Vista could not delete the files with administrative
> privilege. A reboot and all is ok.
> 
> So, something (very very probably an Eclipse thread) was locking the bin tree,
> and the build process malfunctions very badly if folder deletion malfunctions.
If you can reproduce this, can you please try to download procexp.exe and see who is holding this particular folder.

Comment 26 James Fry 2012-06-07 05:27:33 EDT

(In reply to comment #25)
> If you can reproduce this, can you please try to download procexp.exe and see
> who is holding this particular folder.

I know this wasn't aimed at me, but when I get this problem it is practically impossible to debug in this way since the files are almost immediately released after the error. ie, immediately cleaning that project cleanly deletes the folder and a build can start.

Comment 27 Ed Willink 2012-06-20 12:38:32 EDT

(In reply to comment #25)
> If you can reproduce this, can you please try to download procexp.exe and see
> who is holding this particular folder.

It happened again, causing major EGIT confusion about whether a .project file existed or not. 2 hours later I realised that the nightmare bad classpaths were all due to delete problems again.

procexp.exe showed nothing very obviously amiss. Reboot and I'm going again.

Comment 28 James Fry 2012-06-20 13:07:14 EDT

I have now been able to uninstall Symantec Endpoint Protection from my workstation, but the problem appeared to remain until I ran the "cleanwipe" tool from Symantic (the tool to properly remove their products from your machine, including all the various drivers and left over registry keys). So far I have not been able to replicate the issue, but I will continue to monitor and report back.

Clearly, removing the corporate mandated malware checker is sub-optimal, especially given it is a very common product.

Does everyone else who has been experiencing the problem only get this with the Windows7 / Symantec Antivirus combination, or are there things at play? Is the AV a red herring?

Comment 29 Dani Megert 2012-06-21 03:23:19 EDT

(In reply to comment #28)
> Does everyone else who has been experiencing the problem only get this with 
> the Windows7 / Symantec Antivirus combination, or are there things at play? 
> Is the AV a red herring?

I have the same configuration and did not experience the problem so far.

Comment 30 Gunnar Wagenknecht 2012-06-21 03:56:49 EDT

AV is a read herring. I think it has something to do with file locking in Windows. This may be worse with hybrid drives (discs with flash cash).

A simple refresh or clean on the project makes the error go away. Thus, one possible workaround for the compile is to simply retry the delete after a short delay (eg. 250ms).

Comment 31 Gunnar Wagenknecht 2012-06-21 03:58:28 EDT

BTW, another workaround is implemented in the platform build scripts. Instead of using the Ant delete tasks an exec "rm" is used because of similar timing issues with NFS on build.eclipse.org.

Comment 32 Ed Willink 2012-06-21 04:41:57 EDT

(In reply to comment #30)
> AV is a read herring.

FWIW I'm experiencing problems and I use AVG.

> I think it has something to do with file locking in
> Windows. This may be worse with hybrid drives (discs with flash cash).

I have a boring disc drive.

> A simple refresh or clean on the project makes the error go away. Thus, one
> possible workaround for the compile is to simply retry the delete after a short
> delay (eg. 250ms).

In my case it didn't go away even after shutting down Eclipse. Windows couldn't delete either after Eclipse had 'stopped'. Reboot was needed.

Comment 33 James Fry 2012-06-21 04:57:14 EDT

(In reply to comment #30)
> AV is a read herring. I think it has something to do with file locking 
> in Windows

I agree it is a red herring, but the problem only appears to occur for me (and now the rest of my team) when Symantec was installed. As you say, it seems to be related to Windows file locking. I too wonder if it is a timing issue that we were seeing because the IO is now that much faster with the SSD and/or the Symantec drivers were keeping hold of files.

Comment 34 Ed Willink 2012-06-21 05:45:11 EDT

(In reply to comment #33)
> I too wonder if it is a timing issue that
> we were seeing because the IO is now that much faster with the SSD and/or the
> Symantec drivers were keeping hold of files.

A timing issue, Yes, but I suspect that my troubles began when I got bored with EGIT failing to stabilize and so tried to cancel something. I wonder if JGIT has a little daemon that can get orphaned and live on until a reboot.

Comment 35 Missing name 2012-06-21 07:14:29 EDT

We have the same problem on several machines.
All using W7 and Symantec Endpoint Protection.
Although our sysops swear, that the relevant directories
are not scanned.

Comment 36 James Fry 2012-06-21 07:18:17 EDT

(In reply to comment #35)
> We have the same problem on several machines.
> All using W7 and Symantec Endpoint Protection.
> Although our sysops swear, that the relevant directories
> are not scanned.

Our sysops said the same, but I gained permission to have it uninstalled as an exeriment and experienced the same problem. I then got permission to run the "really uninstall Symantec" tool that Symantec provide if you call them up (which removes the Symantic drivers, registry keys, various left over dlls etc). I've not had the problem since running that tool.

Comment 37 Stephan Herrmann 2012-06-21 08:11:21 EDT

Independent of whether or not the bug *can* occur even without AV in the loop
I suggest to follow this route trying to construct a reproduceable scenario
that enables us to actually investigate the problem.

So, aside from having W7 and Symantec Endpoint Protection installed,
what are the ingredients to making this bug happen? What can we do to
increase the probability?


(In reply to comment #27)
> (In reply to comment #25)
> > If you can reproduce this, can you please try to download procexp.exe and see
> > who is holding this particular folder.
> 
> It happened again, causing major EGIT confusion about whether a .project file
> existed or not. 2 hours later I realised that the nightmare bad classpaths were
> all due to delete problems again.
> 
> procexp.exe showed nothing very obviously amiss. Reboot and I'm going again.

This sounds worrisome to me. If windows reboot is necessary to clean the
bogus state, and if that bogus state does *not* manifest in any process holding
a bogus file handle, do we have any theory why reboot could possibly resolve 
the problem??
Is AV activity hidden from procexp.exe??

Comment 38 Olle Lindberg 2012-06-25 05:49:22 EDT

(In reply to comment #37)

> So, aside from having W7 and Symantec Endpoint Protection installed,
> what are the ingredients to making this bug happen? What can we do to
> increase the probability?
> 

I have a 100% repro case described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=332607#c18

Comment 39 Ed Willink 2012-06-25 06:16:32 EDT

(In reply to comment #38)
> I have a 100% repro case described in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=332607#c18

Seems very sensible; just a 'stale' file handle blocking progress

(In reply to comment #20)
> I don't think it's that. Although I'm on Windows 7, I don't use Windows
> Explorer at all.

It's not a Windows Explorer repro; it's a stale file handle issue.

I suspect that the problem is that some multi-directory activity such as a builder or a GIT indexer neglects to close a 'handle' in a finally block when an unforseen exception is thrown.

Comment 40 Eduard Tudenhoefner 2012-12-13 09:06:54 EST

I haven't read all the previous replies, but I also have the same issue. I'm running Eclipse 4.1 on Ubuntu 12.10, 64 Bit, and a SSD. I realized that this issue always comes up when my computer crashes with an opened Eclipse. I managed to solve the issue by deleting particular index files. For example, my workspace log file (located at <path_to_workspace>/.metadata/.log) was full with EOFException, saying that some metadata could not be read, such as

!ENTRY org.eclipse.ui.ide 4 4 2012-12-13 13:25:35.988
!MESSAGE Problems occurred refreshing the selected resources.
!SUBENTRY 1 org.eclipse.core.resources 4 567 2012-12-13 13:25:35.988
!MESSAGE Could not read metadata for '/home/xyzworkspace/.metadata/.plugins/org.eclipse.core.resources/.projects/server-test/.indexes/7/9c/properties.index'.
!STACK 0
java.io.EOFException
	at java.io.DataInputStream.readByte(DataInputStream.java:250)
	at org.eclipse.core.internal.localstore.Bucket.load(Bucket.java:298)
	at org.eclipse.core.internal.properties.PropertyBucket.load(PropertyBucket.java:258)
	at org.eclipse.core.internal.localstore.Bucket.load(Bucket.java:274)
	at org.eclipse.core.internal.localstore.BucketTree.internalAccept(BucketTree.java:98)
	at org.eclipse.core.internal.localstore.BucketTree.internalAccept(BucketTree.java:109)
	at org.eclipse.core.internal.localstore.BucketTree.internalAccept(BucketTree.java:109)
	at org.eclipse.core.internal.localstore.BucketTree.accept(BucketTree.java:76)
	at org.eclipse.core.internal.properties.PropertyManager2.deleteProperties(PropertyManager2.java:102)
	at org.eclipse.core.internal.properties.PropertyManager2.deleteResource(PropertyManager2.java:111)
	at org.eclipse.core.internal.resources.Resource.deleteResource(Resource.java:918)
	... here goes the rest of the stack trace...


After deleting this particular index file and restarting Eclipse, everything worked as before. Any feedback whether the suggestion worked is appreciated.

Comment 41 Alan Cândido 2013-05-13 14:47:46 EDT

I have same problem in Indigo.

Eclipse Indigo Service Release 2
Build id: 20120216-1857
JDT Core 3.7.3.v20120119-37

Thanks

Comment 42 Robert Kiss 2013-09-17 04:20:47 EDT

We also see this problem since some time however we manage to improve the situation recently.
Our situation is like this. We are working on a Eclipse based product and we are using 3.7.2 as target platform. Many of our tests have a flow like:

- import a project into workspace
- perform some actions on project
- delete the project

No mater what we tried on "delete the project" action once in a while we see the "org...ResourceException: Problems encountered while deleting resources".
As development environments we use a mixture of 3.8.2, 4.3, 3.7.2 version of Eclipse. None of the developers have any issues except one (the only one with a laptop) which almost each time when he is forced to do a re-build Eclipse fails to delete some "bin" folders; the above mentioned exception is present in the log. We are all using Windows 7, 64bit.

Recently we tried to invoke the GC if the delete fails and we see a big improvement in the success of our tests. I will try to do some more investigation.

Comment 43 Frank Bravo 2014-09-10 12:50:56 EDT

We recently encountered this problem with some files in output folders that could not be deleted on cleaning or prior to building:

Sample from Eclipse log:

Microsoft Windows [Version 6.1.7601]
eclipse.buildId=4.4.0.I20140606-1215
java.version=1.8.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.jee.product org.eclipse.platform -plugincustomization plugin_customization.ini
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product org.eclipse.platform  -data C:\[...]

This is a continuation of log file C:\[...]\.metadata\.bak_0.log
Created Time: 2014-09-10 16:53:20.213

org.eclipse.jdt.core
Error
Wed Sep 10 16:54:13 CEST 2014
JavaBuilder handling ImageBuilderInternalException while building: [...]-integration-test

org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:816)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:115)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:47)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:180)
	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:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Contains: Could not delete 'C:\[...]\target\test-classes\test.html'.
org.eclipse.core.runtime.CoreException: Problems encountered while deleting files.
	at org.eclipse.core.internal.filesystem.local.LocalFile.delete(LocalFile.java:131)
	at org.eclipse.core.internal.resources.ResourceTree.internalDeleteFile(ResourceTree.java:304)
	at org.eclipse.core.internal.resources.ResourceTree.standardDeleteFile(ResourceTree.java:785)
	at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1979)
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:803)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:115)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:47)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:180)
	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:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
---

In our case this happened reproducably with some but not all HTML, XML and XMI files in our projects, the latter two being part of a logback configuration and IBM deployment descriptors and only in output folders. The file test.html in the sample above was sized 0 bytes.

The locked handles of the files can be viewed with Process Explorer oder Process Hacker. They look like:
File, C:\[...]\target\test-classes\test.html, 0xd80

Additional Information:
While looking for the locked handles we _sometimes_ saw other file handles in Process Hacker all pointing to C:\[...]\.metadata\.plugins\org.eclipse.wst.sse.core\task-tags.properties that were opened one by one until about 20 handles were open, just to be closed and re-opened again one by one. Looks like a timer controlled erroneous loop...
---

With the help of Kohsuke's file leak detector we were able to trace which process opened the locked handles, but obviously "forgot" to close them after use (or was interrupted to do so by another error):

1 descriptors are open
#1 C:\[...]\target\test-classes\test.html by thread:Worker-35 on Wed Sep 10 17:00:23 CEST 2014
	at java.io.FileInputStream.<init>(FileInputStream.java:132)
	at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:377)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:797)
	at org.eclipse.core.internal.resources.File.getContents(File.java:290)
	at org.eclipse.wst.xml.core.internal.tasks.XMLStreamingFileTaskScanner.findTasks(XMLStreamingFileTaskScanner.java:115)
	at org.eclipse.wst.xml.core.internal.tasks.XMLStreamingFileTaskScanner.scan(XMLStreamingFileTaskScanner.java:182)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.scanFile(WorkspaceTaskScanner.java:417)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:243)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:235)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:235)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:235)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:235)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.internalScan(WorkspaceTaskScanner.java:235)
	at org.eclipse.wst.sse.core.internal.tasks.WorkspaceTaskScanner.scan(WorkspaceTaskScanner.java:353)
	at org.eclipse.wst.sse.core.internal.tasks.TaskScanningJob.run(TaskScanningJob.java:205)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
	
	
AFAIK this is the same process like mentioned above in additional information.
---

With this information we disabled "Preferences > General > Editors > Structured Text Editors > Task Tags > Enable searching for Task Tags" as a primary work-around. 

No more problems, except we do not have task tags anymore. So I hope this helps fixing the issue.

THX & G
FB

Comment 44 Jay Arthanareeswaran 2014-09-11 00:03:12 EDT

Thanks for the effort, Frank.

Moving to Web tools for comments.

Comment 45 Nitin Dahyabhai 2014-09-11 00:24:44 EDT

*** This bug has been marked as a duplicate of bug 438209 ***

Comment 46 Nitin Dahyabhai 2014-09-11 00:26:14 EDT

Marked as duplicate based on Frank's leak detection, *but* that leak was introduced in 2014. It would not have been involved when this was reported back in 2010.

Comment 47 Ed Willink 2014-09-11 02:02:08 EDT

(In reply to Nitin Dahyabhai from comment #46)
> leak was introduced in 2014

Yes but the mechanism is interesting. I had noticed that JDT started reporting a leaked stream against org.eclipse.ocl (though I can't see it now).

I wonder how many projects have undiagnosed/unfixed stream leakage?