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

Bug 351823

Summary: [linked source] deleting a linked resource from a read-only project leaves project in an undefined state
Product: [Eclipse Project] Platform Reporter: Helmut J. Haigermoser <helmut.haigermoser>
Component: ResourcesAssignee: Szymon Brandys <Szymon.Brandys>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: mober.at+eclipse, sptaszkiewicz, Szymon.Brandys
Version: 3.7   
Target Milestone: 3.8 M4   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 369493    
Attachments:
Description Flags
Pic showing the error dialog following an attempt to remove the linked resource from a readonly .project file none

Description Helmut J. Haigermoser CLA 2011-07-12 07:43:39 EDT 
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
Comment 1 Helmut J. Haigermoser CLA 2011-07-12 07:45:07 EDT 
Created attachment 199484 [details]
Pic showing the error dialog following an attempt to remove the linked resource from a readonly .project file
Comment 2 Martin Oberhuber CLA 2011-07-12 08:20:50 EDT 
CQ:WIND00164690 

This might be related to bug 322821
Comment 3 Helmut J. Haigermoser CLA 2011-08-08 10:50:47 EDT 
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
Comment 4 John Arthorne CLA 2011-08-08 13:55:25 EDT 
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.
Comment 5 Helmut J. Haigermoser CLA 2011-08-30 05:50:55 EDT 
(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
Comment 6 Szymon Brandys CLA 2011-08-30 08:54:16 EDT 
(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.
Comment 7 Helmut J. Haigermoser CLA 2011-11-02 11:01:32 EDT 
(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
Comment 9 Martin Oberhuber CLA 2012-01-23 11:44:06 EST 
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
Comment 10 Szymon Brandys CLA 2012-01-24 05:46:18 EST 
(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.