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

[Julian Reschke]

Michael B Allen wrote:

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

To allow clients to determine whether two File objects refer to the same 
storage object, and to obtain it's canonical name.

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

The main point here is that it's the server's job to specify what the 
canonical name is. If a client takes over that job, and doesn't do 
*exactly* the same thing as the server, there is a problem. (Because 
then the client will claim that there are two distinct objects when 
there aren't).

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

I think this already happens when two names differ only in 
upper/lowercase, such as "smb://foo/bar" and "smb://foo/Bar". You may 
also want to try "smb://foo/bar " (on NTFS).

Speaking of which,

	(new SmbFile("smb://foo/bar)).renameTo(new SmbFile("smb://foo/Bar"))

currently seems to cause a failure when the remote system is NTFS 
(exception: file not found).

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

I'll try. In the meantime, just consider the following:

- create new file, set lastmodified to something in the past
- write to the file
- check lastmodified

In my tests laatmodified did not seem to change immediately (setting 
jcifs.smb.client.attrExpirationPeriod to 0 seemed to fix that).


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

I'll try to reproduce that.

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

Of course, however the question is *how* to do that. URLs by definition 
contain only ASCII characters, so the SMB URL draft should specify how 
non-ASCII characters (and reserved ASCII characters) should be encoded 
in SMB URLs (even if the code continues to accept non-ASCII characters).

> interpreted by the java.net.URL parser as a reference. Otherwise, we try

That seems correct. If you need a "#" in a URL path segment, you need to 
escape it.

> to comply with RFC2396 wherever possible but there are no plans to be
> completely compatible with it.

Well, if the SMB draft is supposed to be accepted by the IETF, it simply 
has to be compliant to the base spec.


Best Regards,

Julian

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