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

[Allen, Michael B (RSCH)]

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

	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. With
	jCIFS this is done for each SmbFile returned in SmbFile.listFiles() for example.
	There really is no way around this one I'm afraid.