Bug 209177 - [Linked Resources] Need a way to determine location of a deleted linked resource
Summary: [Linked Resources] Need a way to determine location of a deleted linked resource
Status: REOPENED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-08 08:02 EST by Walter Brunauer CLA
Modified: 2015-04-01 09:50 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Brunauer CLA 2007-11-08 08:02:54 EST
Build ID: M20070921-1145

Steps To Reproduce:

1. Create a simple project.
2. Link in any file into the project.
3. Delete the file.
-> Within an implementation of an IResourceChangeListener for IResourceChangeEvent.POST_CHANGE, retrieving the location of the file from the IResourceDelta within resourceChanged() returns an absolute path consisting of the project root location (instead of the link location) and the project relative path.

Expected behavior:

The location should still be the real location.
Comment 1 Szymon Brandys CLA 2007-11-19 09:26:47 EST
I can reproduce it on 3.4 M3 as well.
Comment 2 Szymon Brandys CLA 2007-11-26 09:22:07 EST
The issue here is that the delta is created when the store for the linked file doesn't exist. That's why FileSystemResourceManager returns such a strange location for the resource.
Comment 3 Szymon Brandys CLA 2007-11-26 11:06:36 EST
Actually it's behaving as the API states. If you look at the javadoc for IResource#getLocation, you can read

* If this resource is a linked resource under a project that is open, this
* method returns the resolved path to the linked resource's local contents.
* This value will be null in the case where the location is relative to an
* undefined workspace path variable.

* If this resource is a file or folder under a project that exists, or a
* linked resource under a closed project, this method returns a (non-
* <code>null</code>) path computed from the location of the project's local
* content area and the project- relative path of the file or folder. This is
* true regardless of whether the file or folders exists, or whether the project
* is open or closed.

You are trying to get the location for the file that is already deleted. It results in a non-null path computed from the location of the project's local content area and the project-relative path of the file or folder.

Comment 4 Walter Brunauer CLA 2007-11-27 04:42:48 EST
That's a matter of interpretation, I guess:-)

What option do I have to get the real location of a linked resource, if it is going to be deleted? Is there any notification before the resource actually gets deleted?
Comment 5 Szymon Brandys CLA 2007-11-27 08:18:03 EST
I can't see such an event in Resources. The only one that sounds interesting is PRE_DELETE, but it works only for projects.

Maybe having PRE_RESOURCE_DELETE would help.
Comment 6 John Arthorne CLA 2007-11-27 09:05:15 EST
Changing summary to reflect the real issue. Others have done this by listening to resource change events as resources are created, and maintaining their own table of linked resource locations. It would be useful if we could provide the old location of a linked resource in a POST_CHANGE delta.
Comment 7 Szymon Brandys CLA 2015-04-01 09:50:30 EDT
I am no longer involved in Platform Core development.