Resolver.file mangles UNC paths

[batterseapower]

If on Windows we do something like this:

sbt.Resolver.file("name", new File("//intra/live/foo"))(Patterns("[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"))

Then the resulting FileResolver is built with paths like "C:\intra\live\foo\[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" i.e. the UNC path is replaced with the drive letter of the current working directory, which is definitely not what we want.

The cause of the problem is https://github.com/sbt/librarymanagement/blob/c3dca6880d7b129f708c8b59cf703e52fb4554e3/core/src/main/scala/sbt/librarymanagement/ResolverExtra.scala#L307

i.e.

new File(baseDirectory.toURI.normalize).getAbsolutePath

Because:

new File("//intra/live/foo").toURI() == new java.net.URI("file:////intra/live/foo")
new java.net.URI("file:////intra/live/foo").normalize() == new java.net.URI("file:/intra/live/foo")
new File(new java.net.URI("file:/intra/live/foo")) == new File("\\intra\\live\\foo")
new File("\\intra\\live\\foo").getAbsolutePath() == "C:\\intra\\live\\foo"

I think you can fix this by just dropping the use of normalize since new File(new File("//intra/live/foo").toURI()).getAbsolutePath() == "//intra/live/foo"

[eed3si9n]

@batterseapower Thanks for the report.

I blogged about related topic a while back (http://eed3si9n.com/encoding-file-path-as-URI-reference). I'll compare to see what's happening in this code.

[batterseapower]

Wow, that's a very comprehensive post. I hadn't considered that using nio.file.Path could be an alternative workaround.

[eed3si9n]

Here's my PR - sbt/librarymanagement#337