Details
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8018997 | 7u45 | Xueming Shen | P4 | Closed | Fixed | b01 |
JDK-8001178 | 7u40 | Xueming Shen | P4 | Closed | Fixed | b01 |
Description
I was planning on using the com.sun.nio.zipfs.ZipFileSystemProvider in a project I’m working on, but I noticed a strange behaviour when working with URIs that contain escaped octets – in particular, creating a FileSystem with “jar” scheme for a local filepath that contains spaces always fails with the following exception:
java.lang.IllegalArgumentException: Illegal character in path at index 12: file:/C:/dir with spaces/file.zip
at com.sun.nio.zipfs.ZipFileSystemProvider.uriToPath(ZipFileSystemProvider.java:87)
at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:107)
at java.nio.file.FileSystems.newFileSystem(FileSystems.java:322)
at java.nio.file.FileSystems.newFileSystem(FileSystems.java:272)
I had a look at the uriToPath(URI uri) method and noticed the following snippet that seems to be causing the issue:
String spec = uri.getSchemeSpecificPart();
int sep = spec.indexOf("!/");
if (sep != -1)
spec = spec.substring(0, sep);
return Paths.get(new URI(spec)).toAbsolutePath();
The string returned by getSchemeSpecificPart() is passed back to the new URI(String) constructor. However, getSchemeSpecificPart() returns a string with decoded octets, which means that if the original URI contained any (%20 for spaces for example), they would not be propagated to the modified URI that contains the path to the underlying JAR. Perhaps getSchemeSpecificPartRaw() would be more suitable as it doesn’t decode octets? I have attached a small test case that demonstrates this issue.
Test case:
import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.nio.file.FileSystems;
import java.util.HashMap;
import java.util.Map;
public class Test {
public static void main(String[] args) throws IOException {
File zip = new File("C:\\dir with spaces\\file.zip");
URI uri = URI.create("jar:" + zip.toURI());
Map<String, String> env = new HashMap<>();
env.put("create", "true");
FileSystems.newFileSystem(uri, env);
}
}
java.lang.IllegalArgumentException: Illegal character in path at index 12: file:/C:/dir with spaces/file.zip
at com.sun.nio.zipfs.ZipFileSystemProvider.uriToPath(ZipFileSystemProvider.java:87)
at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:107)
at java.nio.file.FileSystems.newFileSystem(FileSystems.java:322)
at java.nio.file.FileSystems.newFileSystem(FileSystems.java:272)
I had a look at the uriToPath(URI uri) method and noticed the following snippet that seems to be causing the issue:
String spec = uri.getSchemeSpecificPart();
int sep = spec.indexOf("!/");
if (sep != -1)
spec = spec.substring(0, sep);
return Paths.get(new URI(spec)).toAbsolutePath();
The string returned by getSchemeSpecificPart() is passed back to the new URI(String) constructor. However, getSchemeSpecificPart() returns a string with decoded octets, which means that if the original URI contained any (%20 for spaces for example), they would not be propagated to the modified URI that contains the path to the underlying JAR. Perhaps getSchemeSpecificPartRaw() would be more suitable as it doesn’t decode octets? I have attached a small test case that demonstrates this issue.
Test case:
import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.nio.file.FileSystems;
import java.util.HashMap;
import java.util.Map;
public class Test {
public static void main(String[] args) throws IOException {
File zip = new File("C:\\dir with spaces\\file.zip");
URI uri = URI.create("jar:" + zip.toURI());
Map<String, String> env = new HashMap<>();
env.put("create", "true");
FileSystems.newFileSystem(uri, env);
}
}
Attachments
Issue Links
- backported by
-
JDK-8001178 (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets
-
- Closed
-
-
JDK-8018997 (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets
-
- Closed
-
- duplicates
-
JDK-8014852 (zipfs) ZipFileSystemProvider: newFileSystem URI format issue
-
- Closed
-
-
JDK-7108548 (zipfs) ZipFileSystemProvider rejects paths containing spaces
-
- Closed
-
-
JDK-7181278 Paths.get(uri) throws IllegalArgumentException using ZipFileSystemProvider
-
- Closed
-
-
JDK-7181452 Addendum: Bug#7181278
-
- Closed
-
(1 duplicates)