Community
Participate
Working Groups
- I have a directory in one of my projects with many files(ca 8000). - I delete the files using right click and selecting delete - When I press cancel, it takes 30-40 seconds before Eclipse responds. (It continues to churn during this time and does eventually exit as expected). Øyvind
Reassigning to Platform-UI-Inbox (I left IBM 18 months ago..)
Is this delete from the Navigator or the Package Explorer?
not for 3.2
Re-tested in R3.3. If you perform the delete in the Navigator, the resulting operation runs as a Job. Since I work with jobs set to run in background, I tested this by opening the progress view and clicking the "red square" to stop the job. Unfortunately, this did nothing, so we are effectively still broken in the way described by this bug. Since we always complain when other teams don't properly allow their jobs to be cancelled, I'd like to see us fix this one. I also tried this with the package explorer, which seems to have worse behavior. What I did was: - create a new *simple* project - drag an entire eclipse install into the project (just so I would have lots of files to delete) - select the resulting resource directory in the project - choose "Delete" from the pop up menu - answer yes, when asked if you want to delete. At this point, the "yes" button is grayed out, and a progress bar appears on the dialog along with the text "Checking pre-conditions" followed by "Performing action..." (not sure about the exact words of the last string). During the whole time the dialog is visible, the UI is unresponsive, even though this may take several minutes. Adding Martin to the bug to consider this last case.
At least in the Navigator case, I assume we are just calling the resource level delete operation with a progress monitor, which is ignored. Moving to Resources to either fix this or prove me wrong. ;-)
The JDT UI problem with delete is bug 187351.
Created attachment 73482 [details] Fix
This patch isn't enough. When delete is canceled, the resource ends up being out of sync. Here are steps to try: 1) Create a folder with lots of contents (I unzipped an Eclipse build into the folder and then refreshed in the UI) 2) Delete the folder 3) After the delete has started to show some progress, cancel the job 4) Now try to copy the folder -> An error occurs saying the folder is out of sync. We need to catch the operation cancelation in ResourceTree.internalDeleteFolder, do a refresh local on the folder, and then rethrow the cancelation exception. Szymon, can you try doing this. See me for any questions.
Created attachment 73691 [details] Fix 02
I marked Fix 02 as obsolete because it broke one of the workspace tests. I have to investigate it. It possible that the test should be changed.
Created attachment 73710 [details] Fix 03 The problem with tests occurred because before it was assumed, that in case of CoreException during deleting the workspace will be out of sync. In the patch Fix 02 the workspace was synchronized always, even in case of these CoreExceptions.
Reviewed and released. Thanks.
Verified in I20070807-0010. However, in some cases, there was still a noticeable delay between when I hit cancel and when the operation stopped (~15 seconds). Perhaps this was due to updating the tree but the messages being printed still indicated that deletions were occurring. I also noticed that there was more of a delay if I canceled the operation early (as opposed to after it ran for a while).
