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

[Michael B. Allen]

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.

Mike

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