Bugzilla – Full Text Bug Listing
| Summary: | Linked resources are not found when device id of location is lower case | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Gerhard Schaber <gerhard.schaber> | ||||||||
| Component: | Resources | Assignee: | Szymon Brandys <Szymon.Brandys> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | eclipse, john.arthorne, martin.gutschelhofer, mober.at+eclipse, Szymon.Brandys, tomasz.zarna, wbprio | ||||||||
| Version: | 3.3 | Flags: | john.arthorne:
review+
|
||||||||
| Target Milestone: | 3.4 M2 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | hasPatch | ||||||||||
| Attachments: |
|
||||||||||
What if org.eclipse.core.runtime.Path#canonicalize() always pushed the device id to uppercase, when running on Windows? The general strategy in resources (in cases where paths are going to be compared) is to convert paths to canonical form as they cross the API boundary (see bug 119705). This is done for the path parameter in the findFilesForLocation method. It looks like we missed IPathVariableManager#setValue, which should also convert to canonical form. I don't like the idea of changing the case sensitivity of Path, since Path is used in situations that are always case-sensitive, even when the underlying local file system is not. Created attachment 78058 [details]
Fix
Thanks for the patch Szymon, do you have a JUnit for it? I believe IWorkspaceRootTest has some tests like this. I just released some fixes to IPathVariableManagerTest that were broken by the fix, but if you could add a couple of new tests that would be great. Created attachment 78081 [details]
Updated patch
Your fix looks good. However, there is a line near the top of the method that is no longer necessary if we are doing the canonicalization. Here is a small update to your patch.
Patch released. Created attachment 78178 [details]
Extra tests
Could this bug also be a candidate for going into 3.3.1 ? For our commercial product, it would help us live without a questionable workaround on the client side, that's unsure whether it works in all situations. Martin, it would have been possible, but the hopefully final 3.3.1 build is occurring as I write this: http://www.eclipse.org/eclipse/development/freeze_plan_3_3_1.html How about 3.3.2? Extra tests released. This fix caused test failures on Mac (bug 203251), because the fix also causes symlinks in path variable values to be resolved. It's a good thing we didn't release to 3.3.x, because this may have other unwanted side-effects for clients. Verified in I20070917-0010. |
Build ID: I20070323-1616 Steps To Reproduce: 1. Create a project 2. Create a linked folder with a variable 3. Set the value (location) of the variable to c:\temp (use lower case for c:\) 4. Try to lookup the linked folder using ResourcesPlugin.getWorkspace().getRoot().findFilesForLocation(new Path("c:/temp")) The resource cannot be found, because of FileSystemResourceManager.allPathsForLocation. location has always an upper case device id. More information: A solution could be to insert the following line at line 86 (right before relative = testLocation.relativize(location)): testLocation = FileUtil.canonicalURI(testLocation);