Widespread wrong handling of space in File->URI->File conversion?! #35
Comments
|
Why do we need all this Util methods at all? Can't this be replaced with standard java?
Rule 1: Never use spaces in your eclipse workspace ;-) |
Yea, I even had to disallow non-ascii characters for our developers for Workspace and Git repos. |
|
Have no IDE at hand, but we not only support "file:" schema, also other schemas should be possible. So redirecting everything to "new File(url.toURI())" may not always work. |
|
I suspect that some things may even rely on this wrong behavior, so sweeping changes and hoping/assuming all will work well is probably a bad assumption. At least on Windows, user IDs with spaces are not all that rare, but that does generally work okay despite this long list of questionable code... |
|
As far as I remember this was required for remote file conversions, will try to find the related comment and usage. |
I think it would definitely be better to work towards using standard Java API for that.
The 90s are calling and want their problems back. 😄
Although I'm for fixing this, I share that concern. What we can do is to check how the produced URL is used. If it is only used by java API (e.g. a stream is opened from it) it should be save to fix it. If it is for example converted to a String and then later parsed again, we have to ensure that the parsing code can handle a correctly encoded URL. So maybe for such cases we have to ensure that both correct and incorrectly encoded URLs can be handled, then wait some time (one or two years?) and the 'fix' the remaining parts to produce correct URLs. |
|
relates to https://bugs.eclipse.org/bugs/show_bug.cgi?id=145096#c4 |
Do we have any plan to fix this issue? What do you think about the suggested approach? In the |
…platform#35) See original bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=514333 that was only partly fixed. The original fix added -Dosgi.dataAreaRequiresExplicitInit=true system property and changed org.eclipse.core.internal.runtime.DataArea in the way that it doesn't allow to initialize itself if the workspace location was not explicitly specified yet - either via -data or via workspace selection prompt. But the fix in DataArea does not work if bad client code calls Platform.getLocation() *before* calling Plugin.getStateLocation(), because Platform.getLocation() doesn't run into changed DataArea code at all. Exact this happened in commit eclipse-platform/eclipse.platform.resources@a8a8d82 where workspace init order was slightly changed: original code initialized LocalMetaArea first (which then failed as supposed in assertLocationInitialized() if workspace was not set yet), and after that initialized WorkspaceRoot (which uses Platform.getLocation() after the check). Changed code initialized WorkspaceRoot first, and because this uses Platform.getLocation(), the code silently initializes default workspace location even if -Dosgi.dataAreaRequiresExplicitInit=true is set. The current fix makes sure that if the system flag is given, we disallow silent workspace location initialization by adding similar check in Platform.getLocation(). Fixes issue eclipse-platform/eclipse.platform.runtime#35
After fixing eclipse-jdt/eclipse.jdt.debug#66 i took a look where else URLs might be decoded wrong
org.eclipse.core.runtime.URIUtil seems to be wrong even though it's javadoc explicitly says it can handle space
other wrong decodings
new File(.*url.*getPath())(regular pattern search) are inAnother wrong pattern is
new File(.*url.*getFile())in places like:
I do not know when all of this is used, does anybody know if that can be a real issue?
Can we just copy & paste the solution and trust it works?
The text was updated successfully, but these errors were encountered: