Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339752

Summary: [ltk] Improve error reporting when deleting a project fails
Product: [Eclipse Project] JDT Reporter: Martin Oberhuber <mober.at+eclipse>
Component: UIAssignee: Markus Keller <markus.kell.r>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: daniel_megert, helmut.haigermoser, markus.kell.r, ob1.eclipse, Szymon.Brandys
Version: 3.6   
Target Milestone: 3.8 M7   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
screen shot of the error dialog
none
Better?
none
Possible fix none

Description Martin Oberhuber CLA 2011-03-11 14:23:34 EST
Build ID: Eclipse 3.6.1
CQ:WIND00252893

When deleting a project fails because one of its directories is still hoged by a process (such as a cmd shell), the delete operation fails ungracefully with the stacktrace pasted below.

Eclipse should improve its error reporting, telling the user what folder could not be deleted such that the user can investigate the problem.

Steps to reproduce:
1. Create a project foo with a contained folder bar
2. Open Windows cmd prompt and chdir into .../foo/bar
3. Delete Project foo
--> Error message is unfriendly.


org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:799)
	at org.eclipse.core.internal.resources.Project.delete(Project.java:331)
	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:1975)
	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:1975)
	at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Contains: Could not delete '/SIM64-SMP-VSB/h'.
org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.delete(FileSystemResourceManager.java:270)
	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:1944)
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java:786)
	at org.eclipse.core.internal.resources.Project.delete(Project.java:331)
	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:1975)
	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:1975)
	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:\NoScan\ws33\SIM64-SMP-VSB\h\config\vxConfig\cavium.
Contains: Could not delete: D:\NoScan\ws33\SIM64-SMP-VSB\h\config\vxConfig\ipmpls.
Contains: Could not delete: D:\NoScan\ws33\SIM64-SMP-VSB\h\config\vxConfig.
Contains: Could not delete: D:\NoScan\ws33\SIM64-SMP-VSB\h\config.
Contains: Could not delete: D:\NoScan\ws33\SIM64-SMP-VSB\h.
Contains: Could not delete 'D:\NoScan\ws33\SIM64-SMP-VSB'.
Comment 1 Helmut J. Haigermoser CLA 2011-07-22 12:17:10 EDT
Created attachment 200213 [details]
screen shot of the error dialog
Comment 2 Helmut J. Haigermoser CLA 2011-07-22 12:23:04 EDT
@ll,
I've attached the error dialog showing up in such cases.
Can someone from the platform team comment on this, I'm thinking the wording could easily be changed, the term "refactoring" is really misleading since the customer did a "remove project", so the error should be changed to saying:

Error removing the project "name", would you like to:
- Undo
or
- Cancel
the operation?

Note that undoing a deletion is tricky, have we stored the files somewhere so we can recover? I'd guess no, so the dialog might best be changed to a "Cancel" button, with some good advice on how to best recover:

- check for file locks of your project
- check for <whatever>
- reboot in cases you can't find out
- delete the project again


Helmut
Comment 3 Szymon Brandys CLA 2011-07-26 04:12:44 EDT
It would be nice to point at hints in such a case. I think that a link to the help would be good enough here.
Comment 4 Helmut J. Haigermoser CLA 2011-07-26 07:49:37 EDT
(In reply to comment #3)
> It would be nice to point at hints in such a case. I think that a link to the
> help would be good enough here.

Yes, this definitely is more of a documentation change we need, but I would also suggest to try and get the term "refactoring" eliminated from the message since this information, refactoring has failed, is an implementation detail leaking into the customers hands, and he does not know how to deal with that...

Better to state: Deletion has gone wrong, some file on the disk cannot be removed, cancelling our of here, please correct the condition and retry...

Helmut
Comment 5 Oleg Besedin CLA 2011-07-26 09:49:44 EDT
The dialog is org.eclipse.ltk.internal.ui.refactoring.ChangeExceptionHandler.

Note also that "Undo" button on the dialog is misleading as deleted entries are not restored.
Comment 6 Dani Megert CLA 2011-08-08 06:16:19 EDT
I agree we can do better here (improve dialog title and message).
Comment 7 Helmut J. Haigermoser CLA 2011-09-08 13:13:35 EDT
(In reply to comment #6)
> I agree we can do better here (improve dialog title and message).

Thanks Dani :)
So, can we get this change on the way for 3.8?
What changes are possible though, this being part of the refactoring framework
Helmut
Comment 8 Martin Oberhuber CLA 2012-01-23 11:51:11 EST
Ping, any ideas how to proceed on this ?

The issue is really annoying related to external (Makefile) builds ... since it can can happen that the build process spawns a Job from its current directory, which then "locks" the current directory on Windows. Trying to delete a project after having performed a build can then fail with this very unobvious error messages.

I'd really like to see some improvement here.
Comment 9 Dani Megert CLA 2012-02-03 03:29:38 EST
Created attachment 210495 [details]
Better?
Comment 10 Dani Megert CLA 2012-02-03 03:35:59 EST
Created attachment 210496 [details]
Possible fix

Markus, please review. I'm not sure whether replacing the general title with the name of the change works for all our refactorings.

Also, ignoring the 'NullChange' undo needs a review.
Comment 11 Helmut J. Haigermoser CLA 2012-02-03 04:06:18 EST
(In reply to comment #9)
> Created attachment 210495 [details]
> Better?

good! :)
Helmut
Comment 12 Markus Keller CLA 2012-03-16 15:30:55 EDT
The patch was OK for the given scenario, but we better don't create the bad NullChange at all. Result for this bug is still attachment 210495 [details].

Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a5032a72fa1ab61dcfede1919f858f1c8b58b603
Comment 13 Dani Megert CLA 2012-03-19 09:05:08 EDT
(In reply to comment #12)
> The patch was OK for the given scenario, but we better don't create the bad
> NullChange at all. Result for this bug is still attachment 210495 [details].
> 
> Fixed with
> http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a5032a72fa1ab61dcfede1919f858f1c8b58b603

Looks good to me. Thanks Markus.