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

Michael B. Allen miallen at eskimo.com
Wed Jan 15 07:47:12 EST 2003

On Tue, 14 Jan 2003 14:11:07 -0600
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> On Tue, Jan 14, 2003 at 02:27:11AM -0500, Michael B. Allen wrote:
> > On Mon, 13 Jan 2003 12:29:37 -0600
> > "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> > 
> > > In general (not just in the draft) once the URL is parsed the individual 
> > > pieces should be URL decoded.  Parse first, decode second.  Then the 
> > > filename portion (or the pathname, depending on how it gets figured out) 
> > > would be converted to "test#1.txt".
> > > 
> > > I took the fragmentation paragraph out of the latest draft because,
> > > basically, it doesn't make any sense to use fragmentation in a filesharing
> > > protocol.  It makes sense for http because it *knows* that it will be
> > > dealing with hypertext.  Still, a general-purpose parser will see the # as
> > > a fragment delimiter, so it should be escaped.
> > 
> > I'd rather not decode the path component unless absolutely necessary.
> Decode in what sense?  It will need to be un-escaped before it is handed 
> to SMB and, of course, the slashes will need to be reversed.  As far as 
> parsing the path, the only thing you need to remove from the path is the 
> share name (the first element in the path).

No, I mean URL decode. Currently we only un-escape the user info
component. Thus the problem. I do not want to un-escape the path because
we want users to be able to have a path like:

   "smb://server/share/path/to/me @ the beach.jpg"

without requireing the spaces and '@' to be escaped.

> > > I assume that there is some point at which the information passes from the 
> > > Java URL class to the jCIFS code.  This is probably the point at which the 
> > > escapes could be translated and removed from the strings.
> > 
> > Yes, the jcifs/smb/Handler.java has access to this. It might simply be
> > a matter of determining that the java.net.URL class identified a #ref
> > and tack it back on. Boy that would be nice.
> No, there should be no #ref at all.  There is no "meaning" to a #ref in 
> the SMB URL.
> So, if the user *did* add a #ref, then it's a user error.  If the # is 
> escaped, then you would simply need to un-escape the string and *poof*, 
> you have the intended path.

The java.net.URL class parses the URL and *before* the jcifs.smb.Hanlder
gets it. So the '#ref' is getting picked out. I was just saying perhaps
I can append it back on to create an internal path that retains it.

Otherwise I have to un-escape the path component which is slow, requires
more code for this one little use-case, requres that '%' be escaped,
etc. Or you require everything be escaped in which case you have to
re-escape everything before doling out new URLs. etc. etc. etc. Just
more problems.

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