[jcifs] jcifs-0.7.0b5 released
Christopher R. Hertel
crh at ubiqx.mn.org
Wed Oct 23 07:24:41 EST 2002
Ah. This is what I was missing when I read your questions about URL
parsing a while back. Sorry I was being dense...
* URLs that represent workgroups, servers, shares, or directories
must have a trailing slash '/'.
That's a problem from a user-interface point of view. People are used
to entering http://yahoo.com and getting yahoo.com. No trailing slash.
I am surprised that the java.net.URL class doesn't handle this sort of
* Canonicalization does not exceed the host component of the URL. So
smb://host/share/path/ + ../../../../foo/ is canonicalized to
smb://host/foo/ whereas previously the client would have reduced this
That's also a problem, but it may be a problem with the SMB URL format
rather than java.net.URL. I don't know of any other URL form that
assigns meaning to <scheme>:// the way the SMB URL does. That's a
question for the URL gurus. It may be inherently broken.
* Composing a URL with a workgroup and a second paremeter like
smb://workgroup/ + server/share/path/ used to be intellegent enough to
eliminate workgroup. This will now blindly compose the two arguments to
give smb://workgroup/server/share/path/ which is an illegal SMB URL.
This is really smb://workgroup/ + path since we don't know that the path
components represent a server or share until they are evaluated
semantically. Still, I understand the point. If we know (semantically)
that the URL "smb://workgroup/" represents a workgroup then we should
also know that adding anything to it would be invalid. The only way to
handle that situation is to remove the workgroup part and hope that the
next part is a server identifier--a reasonable guess.
I still think that a layer needs to be written above the java.net.URL
layer. Perhaps all it would do is parse and rebuild the URL before
handing it to java.net.URL. Of course, that means having some semantic
information, which means network traffic. Hmmm... I also understand that
the java.net.URL class is final. Dang. Ah, well...
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the jcifs