Community
Participate
Working Groups
Created attachment 176702 [details] Sample project to reproduce the issue CQ:WIND00207330 Build ID: Eclipse 3.5.x as well as Helios (3.6.0) When importing a read-only project into Workbench, an error occurs when: - The project links in other resources - The linked folder exists, but differs in case (e.g. D:\SW vs D:\sw) This is an annoying problem when the .project file is version-controlled, so the CM system insists on making the file writable just to change the case of the linked file. Steps to reproduce: 1. Extract attached SW.zip into D:\ 2. Launch Eclipse, File > Import > General : Existing Projects into Workspace 3. Root dir: Browse to D:\SW\proj 4. Press Finish --> An error dialog pops up: "Error processing changed links in the project description file: File /testProj/.project is read-only". Expected behavior: On Windows host, Eclipse should not report an error. It should not be necessary to make the .project file writeable just to resolve case difference.
Created attachment 176703 [details] Screenshot of the error dialog
The problem seems to be line 667 in Resource.java: localLocation = FileUtil.canonicalURI(localLocation); making the link location canonical makes sense when the link had not existed in the project description before. But I cannot see how this makes sense when the project description is just being read... on a case-insensitive file system (or even a file system that has symbolic links), the contents of the project description should win over what happens to be found on the local file system, since it is often team-shared and must be seen as the correct representation of the project.
Created attachment 176710 [details] Simple patch for the problem Attached is a simple patch for the problem: In case the link is already known to the project description, we skip the step of "canonicalizing" the link and the project description wins. This solves the concrete problem at hand; but further pondering the situation, I'm wondering why the link location is "canonicalized" in the first place. It seems to be wrong doing so at a place that's supposed just to be data storage (clients could canonicalize themselves if they desire to). The only reason that I can think of is dealing with cases where multiple linked resources point to the same link target (aliasing). Will ponder this a bit more, and see how the resources unittests go. What do others think?
Created attachment 176771 [details] Simple patch for the problem - checks for null I updated the patch to handle NPE when links are created.
We should finally commit this into M7, bug 202727 might be related. Can anybody take this, I'm currently dying from other non-eclipse workload.
(In reply to comment #5) > We should finally commit this into M7, bug 202727 might be related. > > Can anybody take this, I'm currently dying from other non-eclipse workload. I can see at least two volunteers. Either Serge, or the one who set the target milestone :-) Both are committers. Of course tests should be added along with the patch.
Created attachment 192167 [details] My proposal v1
We will fix it once bug 338010 is fixed.
We most likely will not address these bugs during this dev cycle.
I am no longer involved in Platform Core development.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
