[jcifs] '/' required at the end of directories

[Christopher R. Hertel]

"Allen, Michael B (RSCH)" wrote:
> 
> > -----Original Message-----
> > From: Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> >
> > [Change of topic.]
> >
> > > > The solution is semantic, not syntactic, I'm afraid.  You'd have
> > > > to contact the server and ask it "what is this thing".  If it's
> > > > a directory, then add the slash.
> > >
> > > Which means we would have to actually connect to the server and query
> > > the resource just to parse it. Ha. No.
> >
> > We do that anyway, in other areas.  We contact servers to discover the
> > semantic differences between an NBT name and a DNS name.  We contact
> > servers to discover NBT vs. naked TCP (port 445) transport.  We do
> > that a lot already.  That's a problem with SMB.
> >
> > In this case, however, I strongly suspect that the semantic differences
> > between a directory and a file won't matter *until after* the server is
> > contacted anyway.  Something like:
> >
> >   smb://server/share/something
> >
> > can probably remain ambiguous until you've talked to the server about
> > it.
> >
> No because it must be known when you create the java.net.URL object
> which is in the SmbFile constructor. We can get away with querying the
> server vs. workgroup distinction. I was going to rip that out but I
> thought users were going to need to do it anyway so we might as well do
> it for them. And it doesn't happen all that frequently. But when you're
> manipulating a big list of URLs and most of them are files you cannot go
> off onto the network and query each to determine if it's really a
> directory. That would be slower than evolution.

I'm not too good at the "it can't be done" scenario, but I do find it easier
to be demanding when I'm not the one writing the code.  :)

Still, I don't like it.  What about a named pipe?  You can't distinguish
that from a directory or file path until you connect either.

You said above that the java.net.URL object needs to know ahead of time what
type of object something is before it accesses that object.  That's
a big chicken-and-egg problem, and I'd go so far as to call it a bug in
the design of java.net.URL.  I probably need a much better understanding
of that class before I complain, but...

The distinction is moot for the HTTP protocol, since the web server will
send HTML or some other mime-type back in any case.  That is, if you enter
"http://server/directory" you will most likely get back an HTML document
that is the listing of the directory contents.

> Just a reminder, because it already got chopped above, the problem is
> internal to the java.net.URL when you create a new URL from a context
> URL object and a relative path like:
> 
>   smb://server/share/dir/ + file.txt => smb://server/share/dir/file.txt
>   smb://server/share/dir + file.txt => smb://server/share/file.txt
> 
> See how the 'dir' got chopped. I believe this is correct URL behavior
> BTW.

The 'dir' got replaced.  Yes, I agree that the above is probably proper
manipulation of relative URLs.  Note, however, that the above is purely
syntactical.  No semantics are applied.

> With jCIFS this is done for each SmbFile returned in SmbFile.listFiles()
> for example.

If I say I want to list "smb://server/share/dir" (no final '/') then a
connection must be made to the server to query "/share/dir".  You can't
can't list it as a file or list the files within it as a directory until
you've connected to it.

If I understand, java.net.URL is requiring that you know those semantics
*before* you make the connection.  I wonder how this is handled for FTP...

Since you have to make the connection anyway, just to list the object, could
you not modify the java.net.URL instance when you've found out that the
object type is incorrect?  If you assume that anything without a trailing
slash is a file until you find out otherwise, and can then add the trailing
slash if you do discover it's a directory...

I don't know how that might work in practice, but then I'm the theory guy.

>         There really is no way around this one I'm afraid.

Then it's a bug.  :)

By the way, the RFC defines path segments as follows:

    path_segments = segment *( "/" segment )

and says:

    The path may consist of a sequence of path segments separated by a
    single slash "/" character.

Given the syntax and the discussion, there is nothing there that requires
a directory to be delimited by a trailing slash.  So, it seems (from my read
of things) that "smb://server/share/dir" is a valid way to specify a
directory.  I also note that Mozilla will add the final slash for me if I
try to access a directory.  That's within the HTTP protocol so I don't
know what semantics are being leveraged.

Hmmm... here's another question for you.  You said:

> With jCIFS this is done for each SmbFile returned in SmbFile.listFiles()
> for example.

...but what if the directory contains subdirectories?  I imagine that when
you list the contents of the directory you will get back information on the
type of each object within the directory.  That would be necessary for a
graphical front-end, for example, that would allow you to browse the share.

Hmmm...  I need to get done with my book so I can try writing some of this
myself.

Chris -)-----

-- 
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