Community
Participate
Working Groups
Build ID: 3.4 Steps To Reproduce: I've got an odd one. Attached is a test case and some explanation on what I'm doing and why I'm doing it... Basically we're creating nested projects. We're trying to create Visual Studio style projects where we have a 'sub' Project with location deep within another Project. This sub Project uses Linked resources to refer to the resources in the parent project. We're then using CDT to try to build the linked source and resolve includes to their actual file system location. This is basically done using path manipulation: IProject.getLocation().append(relativePathToLinkedResource). i.e. the linked resource created in the inner project, is being looked up in the outer project (see BUG246119). Having done this I've tried to findContainers/FilesForLocation(...) which returns a non-empty set. However at this point, getRawLocation(...) is incorrect, as is isLinked(). More information: I've included a patch to the resources test suite which shows the Problem(s) in action. This issue seems to make it impossible to reliably resolve linked resources to locations when nested projects are used...
Created attachment 111673 [details] Patch to LinkedResourceTest to exhibit this and associated problems...
The gist of the problem seems to be that linked resources, when created, arend't add to all their Parent containers. This means that in addition to IWorkspaceRoot.find...ForLocation(), findMember() from the workspace itself also doesn't work reliably.
Hi, I looked at the unit test, and I come up with a different conclusion, that there's no bug but it is "working as intended" but certainly doesn't return what one could expect it should. I changed the test a little bit (as indicated by my "serge:" remarks), but my conclusion is that findFilesForLocation() should return an array 2. According to findFilesForLocation()'s documentation: "Returns the handles of all files that are mapped to the given path in the local file system. Returns an empty array if there are none. The path should be absolute; a relative path will be treated as absolute. The path segments need not be valid names. The resulting files may not currently exist" One could interpret this as the method will return existing resources in the resource tree that have their "getLocation()" pointing to that absolute path passed as argument. Well, there's no real resource that returns the following argument you are passing in the test for getLocation(): "/C:/workspace/ExistingProject/overlappingProjectFolder/OverlappingProject/Folder/linkedFile" Since this path is haft a file system path and half a linked resource path. That path doesn't even point to a proper directory since it assumes "overlappingProjectFolder/OverlappingProject/" exists, while "overlappingProjectFolder" is actually the folder representing "OverlappingProject". What exist is rather the following path: "/C:/workspace/ExistingProject/overlappingProjectFolder/Folder/". What the implementation of findFilesForLocation() does rather, is getting the root path of each project, ans simply looking its file system location is the prefix of the absolute path, then just assumes there's a resource pointing to it, no matter if the path points nowhere at all! Since two projects have location that are prefix to the absolute path provided, the result contains two resource which neither exist, nor can be linked resources. So, in conclusion: findFilesForLocation() is working as intended and construct any resource, no matter if it exist or not in the resource tree. While this may seem not what it should do, I can certainly imagine that changing this behavior would break code that depend on this. The problem in your test is that assuming that callinf findFilesForLocation() with "overlappingProject.getLocation().append(linkedFile.getFullPath())" would return a resource that points to the real linked resource. Instead, you should use "findFilesForLocation(linkedFile.getLocation())" instead, which return 3 resource instead of 2, which one being the The junit test doesn't reveal any bug as far as I understand.
Created attachment 115242 [details] Revised junit test that works properly
So unless I'm missing something, this bug's status should be set as "CLOSED" and the resolution to "INVALID".
Created attachment 115258 [details] Test again (In reply to comment #3) Thanks a lot for your comments Serge! I agree the test was using findFilesForLocation incorrectly. However I think the problem of a linked resource created in a nested project not appearing in the container project is real and a problem. > Instead, you should use "findFilesForLocation(linkedFile.getLocation())" > instead, which return 3 resource instead of 2, which one being the I'm not seeing 3 resources returned. Attached is a much simpler test. I created a linked resource in overlappingProject pointing at a file in the container project. Calling findFilesForLocation on the link's location returns 2 IResources and not the expected 3.
> (In reply to comment #3) > Thanks a lot for your comments Serge! > > I agree the test was using findFilesForLocation incorrectly. However I think > the problem of a linked resource created in a nested project not appearing in > the container project is real and a problem. > I don't think the linked resource in a -physically- nested project should appear in the container project. The way you are nesting the project is not a logical nesting, which eclipse doesn't support, but a physical (file system) nesting. Linked resources are logical resources that do not exist under their resource-parent directories in the file system, so they won't appear either under a container project. In order to support what you are describing, the Core resource plugin would need to support logically nested projects, which it may be vaguely planned for E4. > > Instead, you should use "findFilesForLocation(linkedFile.getLocation())" > > instead, which return 3 resource instead of 2, which one being the > > I'm not seeing 3 resources returned. Attached is a much simpler test. I > created a linked resource in overlappingProject pointing at a file in the > container project. Calling findFilesForLocation on the link's location returns > 2 IResources and not the expected 3. > Sorry, it was a mistype from my part, you are right, 2 resources are returned, as shown in the test method I attached.
In your new "Test again" test, I think it's by design that "/ExistingProject/overlappingProjectFolder/linkedFile" doesn't exists, since it would require logical project nesting.
Created attachment 116171 [details] Test for AliasManager not noticing when outer project is closed Hi Serge, Attached is a test for the alias manager not noticing when the outer project is closed (and a change is made in the inner project to a linked folder...). I'm seeing this for real -- coud you possible review the test to check I haven't made any invalid assumptions?
Created attachment 116174 [details] AliasManager path changedProject = true when project are opened or closed This patch extends the Alias Manager resource change listener to notice when the projects are opened or closed. This prevents the problem exhibited in the previous patch to the LinkedResourcesTests.
(In reply to comment #10) > Created an attachment (id=116174) [details] > AliasManager path changedProject = true when project are opened or closed > > This patch extends the Alias Manager resource change listener to notice when > the projects are opened or closed. This prevents the problem exhibited in the > previous patch to the LinkedResourcesTests. > I looked at the test, and I can confirm that it demonstrate a bug related to having a file under a linked folder resource pointing to a folder in a closed project. The patch also fixes that same bug.
I think that this should be fixed at the root cause - by disallowing project overlap as suggested by bug 245412 comment 4 (masking out the folder of the physically nested project from its container).
Looks like the problem has been fixed :) *** This bug has been marked as a duplicate of bug 258987 ***
