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

[Alan Bateman]

On 30/11/2014 10:27, Francis Galiegue wrote:
> :
> Then what filesystem should the resulting path be associated with?
> Depending on the arguments, if "other" is returned then we get a path
> which is not associated with "us"...
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.

 From what you've said so far then I can imagine the "dropbox" provider 
working a bit like the zip provider so trying out these examples with 
the zip provider should help.

>
> 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.

-Alan