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

[Michael B. Allen]

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.