[jcifs] Equivalent for java.io.File.getCanonicalPath()

Julian Reschke julian.reschke at gmx.de
Sat Jan 31 10:29:47 GMT 2004


Michael B Allen wrote:

> What version of jCIFS are you using?

0.8b.

Michael, first of all many thanks for the feedback. I'll split my 
replies so that we get proper mail threads. I'll also try to come up 
with reproducible examples (I noted the issues only because they might 
have already be known).

> I'm not certain what you're explaining here in general but the jCIFS
> client should perfrom canoncialization like any other client or server.

Well, we got here because SmbFile's getCanonicalPath() is just a 
client-side name canonicalization, while File's getCanonicalPath() 
actually is implemented by asking the (possibly remote) file system. I'm 
not arguing about what is better, it's just *different* and in this case 
prevents me from using SmbFile as replacement for File, and I thought 
that this is what it's supposed to be.

The description at 
<http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#getCanonicalPath()> 
clearly states that this is more than just a form of *name* 
canonicalization. Also note that the method potentially throws an 
IOException:

"IOException - If an I/O error occurs, which is possible because the 
construction of the canonical pathname may require filesystem queries"

> Canonicalization is just factoring out '..'. That's it. Any other

Ths is incorrect, at least for the terminology used by Sun for java.io.File.

> components shouldn't have any effect on how paths are resolved on the
> server. There should be no discrepency between how the client and server
> resolve paths. If there is that is a bug in the client or server and in
> either case jCIFS will be coded to emulate Windows 2000. I would not be
> surprised to learn MS servers handle some strange cases in unexpected ways
> (read -- has bugs) but I can only deal with that when it happends. Anyway,
> what's the alternative?

Doing the same thing as java.io.File. After all, that's what SmbFile is 
supposed to replace, right?

Now, I know little about SMB/CIFS. However it seems that the protocol 
clearly *has* this information. For instance when I use Samba's 
smbclient to access a remote NTFS, and the directory contains a file 
"a", both "dir a" and "dir A" will show the same file, but also report 
that it's really called "a". Looking at the debug information, it seems 
that SMB is sending back the canonical name in the reply. That's what 
I'd like getCanonicalPath() to return.

 > ...

(I'll reply to the remainder separately).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


More information about the jcifs mailing list