Bugzilla – Full Text Bug Listing
| Summary: | [WorkingSets] [CommonNavigator] Should always be able to delete a closed project | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Francis Upton IV <francisu> |
| Severity: | normal | ||
| Priority: | P3 | CC: | francisu, hsoliwal, markus.kell.r, remy.suen, Szymon.Brandys |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Michael Valenta
Do you select "delete contents on disk"? What I select for that option doesn't matter. It's the same result every time. I suspect the problem is that the project's location is messed up somehow (i.e. the Properties view says that the project doesn't exist). As I indicated in the description, there was a custom EFS involved. It's possible the resources tree went dead or maybe the .project file went missing. Though in the latter case I think it's still possible to delete but who knows what's happening in EFS. :| I am performing some deeper analysis of the failure. I wrote a simple plug-in that performs a delete on the project with force set to true. The call succeeds but the project is not removed so it may be a core issue. (In reply to comment #4) > I am performing some deeper analysis of the failure. I wrote a simple plug-in > that performs a delete on the project with force set to true. The call succeeds > but the project is not removed so it may be a core issue. You might want to look carefully at your EFS provider through the delete process. In previous releases (3.5) I have no trouble deleting a project where I have a custom EFS provider, and in the past when I have had issues it has been with how my EFS provider handled things. Yes, I have no doubt that EFS is involved somehow. However, regardless of how ill-behaved an EFS provider is, I should be able to remove the Eclipse project from the Eclipse workspace. The fact that the delete is failing silently is also a concern as it offers little help when trying to debug the issue. The scenario where this happens for me is: 1) have a project with an EFS 2) Close the project 3) delete the content from disk (our EFS is a wrapper on the local file system) 4) Try and deleted the closed project (In reply to comment #6) > Yes, I have no doubt that EFS is involved somehow. However, regardless of how > ill-behaved an EFS provider is, I should be able to remove the Eclipse project > from the Eclipse workspace. Umm, actually not. At least not presently, but that's an issue you are going to need to take up with Platform Workspace. EFS is a pretty low level API and must be very high performance. If the EFS implementation is not following the rules, the resources code will not behave well. I have been through this myself. I'm going to move this over to workspace for their input since it does not seem to be a UI issue. I should point out that I see this behaviour on 3.6 M^ and I have not been able to reproduce on 3.5.2. I am going to try the latest 3.6 integration build (the M7 candidate) to see if the problem is there as well. It turns out this is a UI issue. I had working sets on in the Package Explorer and it was showing me a project that didn't exist in the workspace. It was a Resource Working Set. The delete failed silently because there was nothing to do. (In reply to comment #9) > It turns out this is a UI issue. I had working sets on in the Package Explorer > and it was showing me a project that didn't exist in the workspace. It was a > Resource Working Set. The delete failed silently because there was nothing to > do. I don't follow, the project itself was a Resource Working Set? I'm not sure where we are with this issue as far as what needs to be fixed. If it's in the package explorer that's in a different department (JDT); the project explorer is in the UI. Can you provide some steps for how we can reproduce this? No, the project was in a Resource working set and working sets were the top-most elements in the Package Explorer so the project was visible as a child of the working set but did not exist in the workspace. I don't have a set of steps yet but I'll try and find out how the orphaned project gets left in the working set. I also don't know if the issue is specific to the Package Explorer or if it occurs in the Project Explorer. The next time I see the issue, I will determine the extent of the issue. The issue also occurs in the Project Explorer. I suspect the problem is occurring because a non-existent project is being added to a working set. Since working sets assign no semantics to the objects they contain, the invalid project is added. The views showing the contents of the working set are probably not performing any checks on the children so the invalid project is displayed as a child of the working set. There are two solutions I can see on the UI side of things: 1) The Project/Package explorer content provider should check the children of the working set to make sure they actually exists before displaying them. 2) A delete in the Project/Package explorer should recognize that the project being deleted doesn't exist and prompt with a message that indicates that. I was not able to reproduce the issue using 3.6 M7 and the wrapped file system provided by org.eclipse.core.tests.resources. However it happened couple times in the past, that I ended up having one project shown twice in the package explorer. I was able to delete one of the occurrences, but the another one was unresponsive to all delete actions. Moreover, I'm not able to switch the project explorer to the mode showing working sets as top-level items. It's probably a bug in the project explorer. So I'm guessing Mike is talking about the package explorer. (In reply to comment #13) > Moreover, I'm not able to switch the project explorer to the mode showing > working sets as top-level items. It's probably a bug in the project explorer. > So I'm guessing Mike is talking about the package explorer. Szymon, do you have steps for this issue? If you have not selected any working sets to display, the project explorer will (correctly) not display working sets as top level objects. (In reply to comment #14) > Szymon, do you have steps for this issue? If you have not selected any working > sets to display, the project explorer will (correctly) not display working sets > as top level objects. My fault. It works. I just didn't select working sets properly. Sorry :) I guess this has more to do with the Project explorer/Package explorer, updating QA Contact. I haven't had a chance to look into this is more detail since we ship our product on 3.5 and the problem isn't in that release but I suspect there was a change in the area of working sets in 3.6 that is causing the problem. Changed to CommonNavigator (so I will find this). Hitesh, I always go my bug searched by the summary rather than QA contact, so if it's CNF the summary should be updated. Michael, the working set stuff did change in 3.6, can you see if you can reproduce this in 3.6.0? And if so, can you provide your plugin or steps so that I can easily make this happen? If you can make it happen and provide information from a debugging session which pointed to the smoking gun, that will work too :) I think this is a dup of bug 300368, since comment 9 matches bug 300368 comment 13 (it's not a closed project, but a stale reference in a Resource Working Set). However, I cannot explain why you see a difference between 3.5 and 3.6. Please speak up if you see this with 3.7 M5 or later, or if you think this is a different issue. *** This bug has been marked as a duplicate of bug 300368 *** |