tags:

views:

195

answers:

1

An application I'm working on involves accessing files on network file shares, and we're using URIs to specify the files' locations.

My understanding of the file: URI is that they should take the form of file://+path. In the case of a Windows network share, this path looks something like \\servername\dir\file, so the resultant URI becomes file:////servername/dir/file.

This seems to be working great for Java's URI class, but the Win32 API seems to want a file://servername/dir/file style URI, which Java rejects because it "has an authority component".

Am I understanding network-share URIs correctly? Is there another way to specify a path without Java complaining about the authority?

Edit: We were hoping to be able to store paths as URIs, so as to make use of the scheme-part of the URI to specify other locations (e.g. file: versus other:). But as pointed out, it looks like Java may just have its own issues with URIs...

+1  A: 

It seems that Java is wrong:

Incorrect: file:////applib/products/a%2Db/abc%5F9/4148.920a/media/start.swf
Correct: file://applib/products/a-b/abc_9/4148.920a/media/start.swf

On UNC paths in Java:

The URI class handles UNC paths reasonably well, but has some problems. In the Java class libraries, the string representation of a UNC path is as follows:

new File("//SERVER/some/path").toURI().toString()
                                                -> "file:////SERVER/some/path

In other words, the URI stores the entire UNC path in the path component of the URI, and leaves the server/authority component empty. As long as you consistently use this string representation you will be able to interact successfully with java.net.URI.

dtb
Thanks for your quick response. The second link was especially helpful. While it did make sense to me that the whole path would be stored in the 'path' segment of the URI, I can see that Java does this somewhat inconsistently, so I'll make sure to watch out for that.
SammyIAm