[jcifs] Equivalent for java.io.File.getCanonicalPath()
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
> It changes the case?!
>>(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.
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
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,
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the jcifs