Community
Participate
Working Groups
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.
I can reproduce it on 3.4 M3 as well.
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.
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.
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?
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.
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.
I am no longer involved in Platform Core development.