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

[Michael B Allen]

Julian Reschke said:
>>>(new File("A")).getCanonicalPath()
>>>(new File("a")).getCanonicalPath()
>>
>>
>> It changes the case?!
>
> Yes.

Well I don't think I could justify such a thing. I wonder what their
reasoning was for that.

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

I don't understand this. Canonicalizing a path *is* normalizing. Trailing
dots may be removed during canonicalization although JCIFS does not
permform any Unicode normalization. Please explain further if you think
this behavor is incorrect.

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

Can you give me an example of two URLs that refer to the same file but do
not equate equals() == true?

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

I don't understand this. What does SmbFileOutputStream and close() have to
do with lastModified? Do you have a small code example that illustrates
the problem?

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

CIFS adjusts for timezone and DST and as far as I know jCIFS is fully
compatible with the expected behavor. Ultimately jCIFS emulates
Windows2000. If you determine that jCIFS does not do something precisely
like Windows2000 please let me know.

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

No. JCIFS must support all characters supported by SMB paths or it just
won't work. There are few problems such as '#' in a path will be
interpreted by the java.net.URL parser as a reference. Otherwise, we try
to comply with RFC2396 wherever possible but there are no plans to be
completely compatible with it.

Mike