How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem?

Francis Galiegue fgaliegue at gmail.com
Sun Nov 30 17:19:43 UTC 2014


Hello again,

On Sun, Nov 30, 2014 at 5:43 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
[...]
>
> It will depend on the argument. Suppose we have:
>
> Path p1 = fs1.getPath( ... );
> Path p2 = fs2.getPath( ... );
> assert fs1.provider() == fs2.provider();
>
> Path p3 = p1.resolve(p2);
>
> Suppose p2 is just a file name or a sequence of names (no root component)
> then the result of p1.resolve(p2) will give you Path in file system fs1.
>
> On the other hand, support that p2 is an absolute path then the resolve of
> p1.resolve(p2) will be p2, hence in file system fs2.
>

So far so good, this is what the doc says.

And this reminds me of another question I had about that: why does the
Path API make a difference between having a root component and being
absolute? In other words, is there possibly a case where a Path is
absolute but has no root component or the reverse?

[...]
>>
>> My initial confusion probably comes from the fact that when I tried to
>> copy a file from a zip filesystem onto the default filesystem, I was
>> unable to resolve the path issued from the zip against the path on
>> disk... I had to .toString() the zip path before resolving :/
>
> This is indeed a problematic topic that we don't have support for in the
> API. If a Path has a root component then it's not clear how you could
> convert it to an equivalent Path in the target file system. On the other
> hand, if a Path does not have a root component then you can convert each of
> the name elements to String and use resolve to build up the target Path, as
> in:
>
> Path p1 = ...
> Path p2 = fs2.getPath("");
> for (Path name: p1) {
>     p2 = p2.resolve(name.toString());
> }
>
> Clearly converting the name elements to String may cause you to loose the
> internal representation (it might be bytes for example) but there doesn't
> seem to be anything better.
>

I don't see how this is a problem since the goal is to have a path
suitable for the filesystem of p2; I mean, if you resolve against a
string, you are supposed to create a path against the target
filesystem, right? As such why would the internal representation of p1
matter?

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)


More information about the nio-dev mailing list