[jcifs] Creating file with hash ('#') in filename

[Glass, Eric]

> > > What the example shows is that the HTTP URL handler 
> shipped with Java does what
> > > jCIFS' SMB URL handler does now which is as you put it is 
> syntactically incorrect, not
> > > a URL, and incomplete.
> > 
> > Lost again.  Sorry, that didn't scan.
> 
> Java ships with an HTTP URL handler. jCIFS provides an SMB URL
> handler. You're arguing that the SMB handler should be 
> compliant. I'm just
> pointing out that the HTTP URL handler shipped with Java 
> isn't compliant
> either and Eric's example illustrated that. It took the spaces. And it
> passed them back unescaped. So someone punted on the escapes 
> just like me.
> and probably for transcribability reasons. Don't really know.

I was just trying to point out compatibility versus compliance; the HTTP URL
handler that ships with Java is compatible with URI specs, in that it will
accept all valid URLs.  It is not COMPLIANT with URI specs, however, in that
it accepts nonvalid but reasonable URLs as well.  The point I was trying to
make was that from Chris's standpoint (writing a specification), he should
conform to established standards for URLs in defining what is and what is
not a valid SMB URL.  From Mike's standpoint (an implementor of the
specification), I would argue that jCIFS must be able to accept all valid
URLs.  It may also accept nonvalid, reasonable URLs -- however, it should
not be assumed that any other specific implementation would also accept
these.

As an example, if I hand jCIFS:

smb://server/directory/my file.txt

it may choose to accept this, even though it is invalid.  Some other
implementation may object.  If, on the other hand, I represent this as:

smb://server/directory/my%20file.txt

I would expect that it would be accepted by ALL implementations of the SMB
URL specification.  Even if jCIFS does not require the user to escape the
space character, it must be able to properly handle the case in which the
user does.

> 
> > > Notice it's the URI class rather than the URL class that 
> provokes the exception. I don't
> > > have Java 1.4 so I don't know what toExternalForm would 
> return but I suspect it would
> > > be escaped.

toExternalForm() just creates a string representation (same as
URL.toString(), whatever the URL handler provides -- it doesn't necessarily
escape anything.  Garbage in, garbage out).

> > 
> > Which would cover Eric's final point, about handing the URL 
> back to the 
> > user with correct syntax.
> 

I was just saying it would be nice if jCIFS were able to provide a compliant
output given a noncompliant input.  From an implementation standpoint, I
don't think this would be terribly important -- if the user gave you an
acceptable but nonvalid URL, they should be prepared to get the same thing
back.

For directory listings, however (and other instances in which jCIFS is
generating new URLs), it might be useful to provide valid (i.e., escaped)
output.  Again, as long as jCIFS is at least capable of handling all valid
input, it probably isn't crucial.  But for interoperability, it would be
gravy.

> That's the UR-eye class not the UR-ell. The URI class was introduced
> in Java 1.4. We don't use it. I'm not sure what it's for. Maybe Sun
> decided everything needed to be escaped and came up with the URI
> class. Don't know.
> 

The URI class provides parsing of generic URIs.  It is scheme independent,
and performs syntactic operations on URIs at a higher level (i.e., it will
parse and deconstruct mailto: and other URNs as well).  It does enforce
compliance with the URI specs (it will only accept valid input), so any URL
created from a URI via URI.toURL() is guaranteed to be compliant.  It will
also do unescaping of URIs, so if you have a URL, for example:

smb://server/directory%2Chere/%22my%20file%22.txt

you can do

URI uri = new URI(url.getPath());
System.out.println(uri.getPath());

and get

directory,here/"my file".txt

Although that isn't terribly useful unless you can guarantee that the input
URL will be valid (i.e., fully escaped).


Eric
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.