Hi everyone, Just following up on this to see if anybody has any insight into this issue and whether it is a bug or not. Workaround suggestions would also be appreciated.
Thanks again, Nick On Wed, Jun 17, 2026 at 7:57 PM Nick Tarallo <[email protected]> wrote: > > 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]
