[jcifs] Re: directory must end with '/'

Christopher R. Hertel crh at ubiqx.mn.org
Fri Dec 10 04:32:21 GMT 2004


On Thu, Dec 09, 2004 at 07:43:46PM -0500, Michael B Allen wrote:
> Christopher R. Hertel said:
> >> The 2396 grammer is completely in line with this. The following is NOT a
> >> valid 2396 URL:
> >>
> >> smb://server/share/path/
> >>
> >> It is mearly a fragment of a URL
> >
> > What?
> >
> > Syntactically, that latter is a completely valid URI string.  I can run it
> > through the grammar and it's accepted.
> 
> True. I was being over zelous with my "parent fragment" argument that
> basically is supposed to point out that BOTH:
> 
> smb://[server/[share/[path/[file]]]]
> and
> smb://[server[/share[/path[/file]]]]
> 
> are legitimate URLs but the former should be favored.

They are, as you point out, weak syntax expressions.  Both, as grammars,
will accept similar sets of input.  The first will accept "smb://server/"
but the second will only accept that string if the share name is allowed 
to be empty.

That's the trick in the RFC.  Path segments are allowed to be empty.

> > The term "fragment" is used in
> > the RFCs.  It's the syntax token delimited by the "#" character (as in
> > "index.html#PART2" or somesuch).
> 
> Yeah, that's why I was saying "parent fragment" to mean a prefix.

Which, if I understand the RFC correctly, is called a Base URI.

> > The real grammar in the RFCs show leading slashes.
> 
> No it doesn't.

We could play the Monty Python argument sketch, but I'd really be much 
happier understanding why you say that.

> The distinction of "leading" or "trailing" was invented by
> you and only applies to a parent frament of a complete URL (err .. I mean
> a prefix)

Actually, what I am focusing on is the grammar presented in the 2396.  
(...and yes, I do need to read the updated version to see if that grammar 
has changed).

> But if you can pick which syntactopath representation would be better --
> with the slashes before the [ or after?

Okay, I looked up the revised RFC.  There are actually comments in the 
grammar, and here's an excerpt:

 path          = path-abempty    ; begins with "/" or is empty
               / path-absolute   ; begins with "/" but not "//"
               / path-noscheme   ; begins with a non-colon segment
               / path-rootless   ; begins with a segment
               / path-empty      ; zero characters

I am still not claiming that you're "wrong", I think we're just looking at
things from different perspectives.

> Ans: before so you encourage
> people to use have a trailing slash for directories and the UI or client
> doesn't have to do extra work to straighten it out.
>
> > I will think about changing it for the magazine article I'm doing.
> > I didn't think that was the point of the discussion, however.
> 
> Oh. I did. I asked to review your article to make sure it was technically
> inline with jcifs as the artical is about jcifs. If you trace back to my
> original response the problem was the smb://[server[/path/[file]]]
> condense grammer. JCIFS will NOT work with URLs that do not have trailing
> slashes and that syntactopath representation would lead people to believe
> otherwise. If the article is about jCIFS then I think you should use
> smb://[server/[path/[file]]]. That's all I've been trying to say.

That is, I grant you, where we started.  The discussion encouraged me to 
look more closely at the RFC grammar and the comments that Julian pointed 
out for me in other URI specifications.

Now, I think, it's worth taking that and applying it both to jCIFS and to 
the SMB URI draft.  There's a lot I have learned.

I am willing to listen and learn and to be wrong.  Where I am right now is 
this:

- Throwing the exception in the .list() method if the URI doesn't end in a
  slash makes sense.  It's similar to the 301 redirect that HTTP servers
  send by convention (as Julian pointed out).  I believe, however, that 
  this is a semantic issue, not a syntactic one.

- The RFCs I've been reading keep talking in terms of the slashes 
  being "before" the path segments.  Eg., section 3.3 of the updated 
  RFC2396BIS says:

     If a URI contains an authority component, then the path component 
     must either be empty or begin with a slash ("/") character.

  That tells me that that the URI "smb://server/" has the same form as
  smb://a/b, but that the b segment is empty.

I won't go further because I don't want to split any more hairs.  I want 
to get on the same page here so I'm more interested in understanding what 
it is that you're seeing that I'm missing.

Help me out.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


More information about the jcifs mailing list