Extending the default file URL protocol handler to work with Window shares?

[Filip Larsen]

I have been trying to use the URL class in an application for specifying
files on a Window share (with syntax "\\host\path\file"), but without much
success.

I am using some guesswork here since the two classes in play, Handler and
FileURLConnection, both are in the sun.net.www.protocol.file package to
which I don't have any source code, but the following seems to happen:

- a file Handler singleton is installed when the first file protocol URL is
used,
- an url is made such that url.toString().equals("file:\\host\path\file"),
- the url gets an openConnection call,
- the url delegates the openConnection method call the Handler singleton,
- the Handler singleton checks if File("\path\file") exists, which it
doesn't,
- the Handler falls back trying the URL "ftp://host/path/file" instead,
which also fails.

So, the problem as I see it is that the file Handler is stripping the
hostname away from the string it gives File and I have not been able to find
any URL syntax for which this doesn't happen.

Since the File class have no problems with the "\\host\path\file" notation I
then tried to install a very simple file protocol handler with
URL.setURLStreamHandlerFactory():

public class MyURLHandlerFactory implements URLStreamHandlerFactory {
public URLStreamHandler createURLStreamHandler(String protocol) {
if ("file".equals(protocol)) return new MyFileURLStreamHandler();
return null;
}
}

public class MyFileURLStreamHandler extends URLStreamHandler {
protected URLConnection openConnection(URL u) throws IOException {
return new MyFileURLConnection(u,new File(u.getPath()));
}
}

public class MyFileURLConnection extends
sun.net.www.protocol.file.FileURLConnection {
public MyFileURLConnection(URL u, File f) {
super(u,f);
}
}

where the last class is necessary because
sun.net.www.protocol.file.FileURLConnection only have one constructor which
is protected. Note that in my case, u.getPath().equals("\\host\path\file")
which gives a File that actually exists.

This handler almost works. It seems to work fine with the normal file URL's
that are used during application start-up and also with those special
windows-URL's I feed it. However, now the file URL's are no longer parsed
into a canonical form (like "file://host/path/file") so building new
relative URLs from those backslash-URLs do not work except for very simple
cases like new URL("file:\\host\path","file"). More complicated things like
new URL("file:\\host\path","../otherpath/file") ends up as new
File("\\host\path/../otherpath/file") which is not working.


One should think that the problem of getting Java URLs to support Windows
UNC paths must have been solved before by someone, but a quick visit to
google did not show up anything. So now, before I go spending a big effort
to research and write my own full-fledged FileURLConnection, I would like to
ask if any of you have any pointers on how I go about adding "general"
support for Windows UNC paths to the URL system?

And if anyone have the Java 1.4 source code for those two "unsupported" sun
classes mentioned above and are allowed to show it to others, I'd almost
give a body part to see it

 

[Cedric]

Just an idea:
If you want to access \\host\foo\file, you have to use in Java:
File("\\\\host\\foo\\file") because the backslash will be interpreted, and
the result of the \\host\foo\file would be for java
\host(form-feed)oo(form-feed)ile. Backslash marks an escape character.

Cedric