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

[Glass, Eric]

>From the standpoint of the robustness principle, I would look at it this
way:

The draft should reflect conformance to existing generic URL specifications.
jCIFS should accept all SMB URLs which conform to the draft.
jCIFS MAY accept SMB URLs which do not conform to the draft, but are
"reasonably" broken.
In an ideal world, jCIFS would be able to output a conformant URL given an
accepted but nonconformant input (for compatibility with other agents).

As an example, all agents should be able to accept this as a valid URL:

smb://server/directory/file%23stuff.txt

Likewise, all agents should be able to PARSE (although not necessarily
accept as semantically valid):

smb://server/directory/file#stuff.txt

Assuming that the draft does not specify a semantic for fragments,
interpretation of this may vary.  jCIFS may append the fragment onto the
filename; another agent may indicate that fragments are semantically
meaningless in the context of an SMB URL and give an error.

jCIFS MAY be able to parse:

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

But other agents should not be required to do so.  jCIFS (and all agents,
for that matter) SHOULD be able to represent this as:

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

In an ideal world, doing:

URL url = new URL("smb://server/directory/file stuff.txt");
System.out.println(url.toExternalForm());

would output:

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

to enable jCIFS to output compliant URLs regardless of what particular
inconsistencies it chooses to accept.  Sun's implementation of HTTP URLs
does not do this, however, so I wouldn't expect jCIFS to be required to do
so.  For example, if I do:

URL url = new URL("http://server/directory/file stuff.txt");
System.out.println(url.toExternalForm());

I get (the invalid):

http://server/directory/file stuff.txt

Note, however, that doing:

URL url = new URL("http://server/directory/file stuff.txt");
URI uri = new URI(url.toExternalForm());

throws:

java.net.URISyntaxException: Illegal character in path at index 28:
http://server/directory/file stuff.txt
	at java.net.URI$Parser.fail(URI.java:2701)
	at java.net.URI$Parser.checkChars(URI.java:2872)
	at java.net.URI$Parser.parseHierarchical(URI.java:2956)
	at java.net.URI$Parser.parse(URI.java:2904)
	at java.net.URI.<init>(URI.java:565)


Eric


> -----Original Message-----
> From: Allen, Michael B (RSCH) [mailto:Michael_B_Allen at ml.com]
> Sent: Wednesday, January 15, 2003 9:03 PM
> To: 'Christopher R. Hertel'
> Cc: jcifs at samba.org
> Subject: RE: [jcifs] Creating file with hash ('#') in filename
> 
> 
> 
> 
> > -----Original Message-----
> > From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> > 
> > > 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.
> > 
> > Only if you want to bypass the standard syntax for URLs.  :)
> > 
> 	You mean HTTP URLs. It's the HTTP URL that uses '#'. We 
> don't have any
> 	use for it.
> 
> > The # (if unescaped) in that position should be a delimiter and the
> > pedantic way to handle it is to cough back an error.
> > 
> 	For HTTP URLs. For SMB URLs this remains to be seen. We cannot
> 	conform to the HTTP URL closely without a cost. The 
> main problem is that
> 	SMB path names need to represent just about any 
> character including
> 	Unicode which we haven't even touched on. I personally 
> do not want to
> 	decode paths. That is very costly. It is very likely 
> that SMB URLs will contain
> 	reserved characters like space, '@', and '#'. We cannot 
> accept both encoded
> 	and non encoded URLs because URLs returned by jCIFS 
> will need to be
> 	encoded. Even if you pass back whatever was passed in 
> how do you handle
> 	URLs derived from a parent during a list() operation. 
> It get's very messy. Can
> 	someone give me a reason why we *have* to require URL 
> encoding of the
> 	path component? Otherwise I think we should punt the 
> '#ref' and just integrate
> 	it into the path. Anything we would use it for can be 
> done with a query_string
> 	parameter.
> 
> 	Incedentally speaking of query_string parameters we got 
> lucky with the '?'
> 	character. That *is* reserved in SMB pathnames. It's a 
> wildcard character.
> 	Otherwise we really *would* have to require escaping 
> path components.
> 
> 	Anyway it looks like just tacking the '#ref' back onto 
> the path component in
> 	Handler.java is going to do the trick. NetworkExporer 
> doesn't like it but that's
> 	because the SMB URLs are going through the browser as 
> part of the path. In
> 	this case they *are* HTTP URLs and as such need to be 
> escaped. I'll leave
> 	the NetworkExplorer fixes till later I think.
> 
> 
> 
 
**************************************************************************
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.