[jcifs] Property Inconsistencies (Davenport)

[Michael B Allen]

Mike McDonald said:
> Hi everyone.  My apologies, as I'm not entirely sure this question belongs
> here.
>
>
>
> I am testing Davenport as a file sharing solution.  I have one problem
> that
> is giving me a particularly hard time, and I'm just curious about the
> difference in how jCIFS handles shares versus directories.  The reason for
> my question is that when I attempt to open a share (TYPE_SHARE) in Web
> Folder view, I am unsuccessful.  If I attempt to open the same physical
> directory (TYPE_FILESYSTEM) as a Web Folder it succeeds.  I've outlined a
> couple interesting items below (from the PROPFIND response).  Please note
> the following differences:
>
>
>
> 1.	In the href element, the href has a trailing '/' when accessing via
> TYPE_FILESYSTEM.  This '/' is appended by davenport.  Does it have any
> significance to jCIFS?

Yes. An SMB URL that refers to a server, share or directory must end with
a '/' or the java.net.URL class will not properly construct derived URLs.
To ensure that this condition is true, jCIFS will check to see if the URL
represents a directory (when it can without going to the wire) and
generate an error if the trailing '/' is not present.

> 2.	The getlastmodified and creationdate elements are different
> depending on how the request was made (SmbFile.lastModified()).  (No time
> has elapsed?)

I don't understand this statement. I suspect it has something to do with
WebDAV but the SmbFile.lastModified() method has been known to return 0
for directories under certain conditions (that I believe are limited to
Win95/98ME).

> 3.	The getcontentlength element is different depending on how the
> request was made (SmbFile.length()).

Ditto above about directories. Are you using Windows 95/98/ME?

> Can anyone hazard a guess as to why these might differ depending on if the
> resource is accessed as a share versus as a filesystem?

Well shares and directories are quite different in practice. JCIFS has
taken  great care to make all node types behave as one would expect given
the same set of available operations but there are differences (e.g. you
cannot delete() a server) and some might be artifacts of the underlying
CIFS behavior that may or may not be practical to repair.

>                 <getlastmodified w:dt="dateTime.rfc1123">Thu, 01 Jan 1970
> 00:00:00 GMT</getlastmodified>
>
>                 <displayname>shares/</displayname>
>
>                 <creationdate
> w:dt="dateTime.tz">1970-01-01T00:00:00.000Z</creationdate>

So you're getting 0 for last modified on a share? That doesn't surprise me
at all. This is what is returned by the CIFS server. If there is time
information about the share I don't beleive jCIFS has access to it though
RAP functions.

Mike