Community
Participate
Working Groups
On Windows, when a Path object is created using IPv6 address path (like \\2001:1890:110b:31e8:a9c:2999\level\folder), then Path API incorrectly considers the colon as the device separator (the Path Ctor() has Windows specific code for separating the device from the remaining path string). Due to this, the Path API is not really helpful when the address strings can contain local, IPv4 and IPv6 addresses. Currently, I am using Path(null, pathString) as an alternative for dealing with the IPv6 specific address strings. I feel that Path API can be made IPv6 compatible which should be capable of dealing any sort of address paths.
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
(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.
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.
(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
