Bug 329749

Comment 1 John Arthorne 2010-11-09 13:21:18 EST

Moving to Equinox as IPath lives in Equinox Common.

As described in the javadoc, IPath represents an ordered collection of string segments, with an optional device id. It is not intended to represent arbitrary network addresses.  Something like java.net.URI is probably more appropriate as a general purpose network address identifier. So, I would be inclined to mark this as WONTFIX, but I would be curious to know if there are reasons why you must use a Path. For example are you invoking an Eclipse API that takes an IPath argument, in an API that otherwise supports arbitrary network locations?

Note one special case that IPath does support today is UNC addresses, since they can be used as local file system paths on Windows platforms.  However the ':' character is illegal in UNC paths as well so we are not imposing any constraint that doesn't exist generally for UNC paths. For details see:

http://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_UNC_path_names

Comment 2 Praveen 2010-11-18 06:18:10 EST

(In reply to comment #1)

> this as WONTFIX, but I would be curious to know if there are reasons why you
> must use a Path. For example are you invoking an Eclipse API that takes an
> IPath argument, in an API that otherwise supports arbitrary network locations?

Yes John. We use Path API for operating on the arbitrary locations either the local file path or the remote locations (could be both IPv4 or IPv6) as well, depending upon the user input in a wizard.

On the other note, we have a scenario to create a link folder to a target folder in a IPv6 machine (like //2001:234:3123/test). The API Resource.createLink() does not accept the IPv6 folder location, as internal validation code in FileStoreRoot.init() makes use of Path(String) that converts "\\2001:234:3123\test" into device as "2001:" and the fullPath as "234:3123\test", which is entirely incorrect.

I feel the below code change in Path (String) ctor should take care :
--------------------
/*
*  Path starting with \\ is a UNC Path, so there is 
*  no need to extract device in that case. Otherwise,
*  fullPath can be matched against IPv6 regex as well
*  in order to ignore the device seperation part.
*/
if (WINDOWS && !fullPath.startsWith("\\")) {
--------------------

Please share your thoughts on this.

Comment 3 Praveen 2010-11-19 06:23:53 EST

Created attachment 183461 [details]
Suggested patch

The patch contain the code changes that makes Path API not to separate the device part when it receives UNC path.
Please let me know your thoughts.

Comment 4 John Arthorne 2010-11-19 10:08:18 EST

(In reply to comment #2)
> On the other note, we have a scenario to create a link folder to a target
> folder in a IPv6 machine (like //2001:234:3123/test). The API
> Resource.createLink() does not accept the IPv6 folder location, as internal
> validation code in FileStoreRoot.init() makes use of Path(String) that converts
> "\\2001:234:3123\test" into device as "2001:" and the fullPath as
> "234:3123\test", which is entirely incorrect.

\\2001:234:3132\test is not a legal UNC path. The correct UNC representation of this is:

\\2001-234-3132.ipv6-literal.net\test

I don't think supporting a deviation from the UNC spec is really helpful here. It might help in limited cases, but eventually clients will probably run into a Windows API that correctly fails. You're better off using the correct ipv6 encoding for UNC. See the following document, under the section "IPv6 Address Nomenclature Used for a UNC Path":

http://msdn.microsoft.com/en-us/library/bb743585%28BTS.20%29.aspx