Hello,
I have encountered a possible regression between VFS 2.9.0 and 2.10.0
related to file path encoding.
I would expect resolving a file from a URL and then resolving the URL
returned by getURL() to preserve the same path, but that does not
appear to happen in 2.10.0. The following test case from my project
passes with 2.9.0 but fails with 2.10.0:
@Test
public void vfsGetUrlRoundTripIdentity() throws Exception {
Path tmp = Files.createTempDirectory("vfs-roundtrip");
try {
Path child = tmp.resolve("outside%text[inside%text]tail");
Files.createDirectories(child);
FileSystemManager mgr = VFS.getManager();
FileObject a = mgr.resolveFile(child.toUri().toString());
FileObject b = mgr.resolveFile(a.getURL().toString());
assertEquals(a.getName().getPath(), b.getName().getPath());
} finally {
FileUtils.deleteDirectory(tmp.toFile());
}
}
The assertion failure is:
Expected:
.../outside%25text[inside%25text]tail
Actual:
.../outside%25text[inside%2525text]tail
I noticed that URIParser.decode() changed in PR #438 [1], and I am
wondering whether the behavior could be related to that change. It
appears that content inside brackets is treated specially to avoid
decoding IPv6 hosts, but I am not sure whether that logic should apply
to local file paths.
Is this expected behavior, or does it sound like a regression?
Thanks,
Nick
[1]
https://github.com/apache/commons-vfs/pull/438/changes#diff-731c9fd149c7d934456163a6eb8c1afebc6be0669986e8ccf5092f164ea0cd30R166
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
