Community
Participate
Working Groups
Build Identifier: I20110613-1736 Removing a linked source from a project requires modifying the .project file. If that file happens to be read-only the operation will fail, and Eclipse will bring up a dialog saying as much. However, the provided options to continue, "Undo" and "Abort" both lead to the same result: - .project is untouched - but the Project Explorer does not show the Linked Resource anymore. Somehow the information about the linked resource gets out of sync, nothing of the following helped: - restart Eclipse - close/open project The following worked: - delete project without deleting the resources on disk - import the project The desired behavior is for the operation to first check write access to .project before continuing with the operation. Alternatively the rollback using the "Undo" button should restore the linked resource to the Project Explorer / Package Explorer. Reproducible: Always Steps to Reproduce: Resource Perspective: 1. Create a general project: test 2. Right click on the project: New-Folder 3. Advanced >> Linked Folder (any will do) 4. Finish 5. Set .project read only (like a CM would do) 6. Right-click on the linked resource: Delete 7. Neither option out of the created error dialog will work: Undo, Abort
Created attachment 199484 [details] Pic showing the error dialog following an attempt to remove the linked resource from a readonly .project file
CQ:WIND00164690 This might be related to bug 322821
Hi All :) Can we get a comment from the platform team, this bugs seems like an easy fix: check the write-flag of .project before actually removing linked resources from the project. However, what looks easy from the outside usually is a lot different internally... Helmut
I can't speak for the Undo/Abort dialog - that comes from the refactoring system. I'm not sure what exactly Undo tries to do when the operation fails. I can see why the inconsistency occurs - Resource#deleteResource removes the resource from the workspace tree before attempting to write the description. Thus when writing the description fails the resource is already gone. These steps could probably be reversed to avoid the immediate problem - delete links/filters before deleting the resource from the tree. We should probably also perform a Workspace#validateSave here to give a team hook a chance to checkout the resource. Szymon B, can you take this, or perhaps it is a good one for Gosia or Szymon P.
(In reply to comment #4) > Szymon B, can you take this, or perhaps it is a good one for Gosia or Szymon P. Szymon, Gosia, what's your thoughts on this? Thanks a lot! :) Helmut
(In reply to comment #5) > (In reply to comment #4) > > Szymon B, can you take this, or perhaps it is a good one for Gosia or Szymon P. > Szymon, Gosia, what's your thoughts on this? > Thanks a lot! :) > Helmut I haven't looked at it closer yet. I'll let you know soon.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Szymon B, can you take this, or perhaps it is a good one for Gosia or Szymon P. > > Szymon, Gosia, what's your thoughts on this? > > Thanks a lot! :) > > Helmut > I haven't looked at it closer yet. I'll let you know soon. Thanks Szymon, please let me know if you need any more input to reproduce or fix this! :) Helmut
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=f4f55cb730121eb31a95c6536a560d993d7e05a6
This has been reported by a customer of ours. Is the fix safe enough for backporting into 3.7.2 ? Or is the time window for 3.7.2 fixes already closed ? Thanks, Martin
(In reply to comment #9) > This has been reported by a customer of ours. > > Is the fix safe enough for backporting into 3.7.2 ? > Or is the time window for 3.7.2 fixes already closed ? > > Thanks, > Martin It's pretty late. We are in RC3 for 3.7.2, but still can release important fixes. The fix is safe, so I'm raising a bug to backport it to 3.7.2.
