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

Julian Reschke julian.reschke at gmx.de
Fri Jan 30 20:53:11 GMT 2004


Michael B Allen wrote:

>>I'm looking for a jcifs equivalent of java.io.File.getCanonicalPath().
>>Note that SmbFile.getCanonicalPath() does *not* do the same.
>>
>>For instance, given a filename "a" on an NTFS filesystem,
>>java.io.File.getCanonicalPath() will return "a" for each of
>>
>>(new File("A")).getCanonicalPath()
>>(new File("a")).getCanonicalPath()
> 
> 
> It changes the case?!

Yes.

>>(new File("A ")).getCanonicalPath()
> 
> 
> Trimming leading and trailing space is no problem. I'll fix that. I didn't
> know it was a problem.

No no no, *don't* let the client do it. It is absolutely important that 
what is returned here is what *the server* says is the canonical name. 
Missing some kind of normalization (trailing dots? Unicode 
normalization?) may cause the client to think that two things are 
different, leading to potential security issues.

>>and so on... (alternatively I'd need a way to find out whether two
>>distinct SmbFile objects refer to the same file on the remote filesystem).
> 
> 
> That's precisely what SmbFile.equals() is supposed to do. If it doesn't
> it's a bug and please let me know.

It doesn't.

Speaking of which, I did some more testing and have a few more questions:

1) Caching of lastmodified(): after new SmbFile(), new 
SmbFileOutputStream(), .close, lastmodified() on the SmbFile still 
returns 0.

2) Timezone handling: it seems that timestamps returned by the server 
are handled in a timezone-aware way. That is, if the client thinks that 
the timestamp belongs into a time interval where DST was in effect, an 
additional hour is subtracted.

3) URL handling: according to RFC2396, URLs never ever contain blanks or 
non-ASCII characters. However, jCifs accepts those, returns them in this 
format and the documentation even uses names with blanks in examples. 
This probably should be cleaned up. I assume that the support can't be 
removed due to backward compatibility reasons?


Best regards and thanks for the feedback,

Julian







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


More information about the jcifs mailing list