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

[Michael B Allen]

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.

> The term "fragment" is used in
> the RFCs.  It's the syntax token delmited by the "#" character (as in
> "index.html#PART2" or somesuch).

Yeah, that's why I was saying "parent fragment" to mean a prefix.

> The real grammar in the RFCs show leading slashes.

No it doesn't. 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)

>> both:
>>
>> smb://[server/[share/[path/[file.txt]]]]
>> and
>> smb://[server[/share[/path[/file.txt]]]]
>>
>> are legal but which one makes more sense? Would you rather encourage
>> users
>> to write:
>>
>> smb://server/share/path
>> or
>> smb://server/share/path/
>
> I'm not planning on encouraging users to one or the other.  What this
> conversation has shown me is:
>
>   - both are syntactically correct.
>   - neither are valid until they reach the server.
>
> It's the server that knows the real semantics then that's the place to ask
> the question.

But if you can pick which syntactopath representation would be better --
with the slashes before the [ or after? 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.

Mike