Community
Participate
Working Groups
build I20040303, with latest UI and Runtime from head, plus workspace prompt patch (bug 32147). - start target with @noDefault as its workspace location (-data arg) - choose a workspace directory like d:\eclipse-new\browser-workspace - it opens the workspace - create a new project A - get properties on the project - the info page shows the location as \d:\eclipse-new\browser-workspace - stepping through it, Platform.getLocation() is returning a leading slash.
Turns out this is a major problem. I launched a target using the new workspace prompt, which sets the instance data location to a URL with protocol "file" and path "/d:/eclipse- I20040303/eclipse/workspace", which was obtained with File.toURL(). I then created project A, folder A/B and file A/B/C.txt. The editor did not find C.txt and it did not show up in the Navigator. When I refreshed B, it disappeared. The folder and file were there in the filesystem though. Thinking this might be related to this bug, I changed the workspace prompt code to create the URL directly rather than using File.toURL(), with path "d:/eclipse-I20040303/eclipse/workspace". This fixed the above problems. Please advise on the correct format of URL to pass to the runtime.
The leading / is perfectly legal. As I understand URL/URI, if you do NOT have a leading / the value is opaque. Technically it means you should not be able to do path math etc. In the case of URLs it seems that the implementation still allows this. There have been hints that URI is more restrictive. In any event, for backward compatibility Platform.getLocation() should be updated to trim the leading /s if any. This is quite complex as there may in fact be /// (three /) and this would also be valid. I believe the that new File (aFile.toURL().getPath()) should always work. As a workaround in the near term the workspace prompt should be careful to not put the / in. Passing to Pascal as he was also looking at a case where the install location having spaces caused issues. This may be related to not encoding the URL (converting ' ' to '+', ...)
I noticed in the spec for File.toURL() that it says it does not do character conversion. They suggest converting to a URI first for new code: File.toURI ().toURL().
I tried the File.toURI().toURL() approach but got the same results as just toURL -- i.e., it didn't work. For the workspace prompt (for now) I'll build the URL using a constructor; hopefully in the future we'll be able to go back to the File.toURL approach.
For consistency lets just ensure that the result of getLocation does NOT have a leading /. This is the right answre for compatibility.
I also notice that if you run with -showLocation, the path that's shown in the titlebar has a trailing slash, which I don't think it did before.
I tried 2.1 with -showLocation and found that it basically reports whatever you set in the -data arg. start with -data c:\foo and you get "c:\foo". Use -data c:\foo\ and that is what -showLocation displays. In any event, I have changed getLocation() to "normalize" the value (used new File(value).toString() as the approved way of normalizing a file location in Java (see java.io.FileSystem)). This means that it will not have a leading \ (before the device) and will not have a trailing \. This last point does not appear to be spec'd anywhere that I could see but is the behaviour observed on JDK 1.4.2_04. I want to do a bit more testing before releasing
released.
