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

Michael B. Allen miallen at eskimo.com
Sat Jan 18 09:47:28 EST 2003

On Fri, 17 Jan 2003 08:37:10 -0500
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> > 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.

Ok. So there is a distinction in that the HTTP URL handler will correctly
accept the escapes whereas the SMB URL handler would not.

I suppose it is possible that in addition to the garbage in garbage out
technique we could selectively escape the 7 ASCII characters reserved
in RFC2396 but those that are permissible in SMB filenames:

  " #%`^{}"

But this will still pollute the URLs as we drill down in file browsers.

> > > > 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.

You would really prefer that they be escaped by default? That would
require that applications decode every URL before display.

> 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.

If we start escaping I don't see how we cannot escape new URLs. There
would be no way to know if the '%' really signalled the beginning of an
escape for example.


A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived. 

More information about the jcifs mailing list