[jcifs] Property Inconsistencies (Davenport)

[Julian Reschke]

Michael B Allen wrote:

> 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

Same over here...

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

In which case Davenport should not return a last modification date in 
PROPFIND.

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

Looking at my traces, this seems to be the reason why the webfolder 
client rejects the collection. I may be able to verify this tomorrow.

This is almost certainly a bug either in Davenport or JCifs (returning 
DAV:getcontentlength with a value != 0), but in practice, the webfolder 
client *should* ignore that (after all, WebDAV collections MAY have 
content).

> ...

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

Regards, Julian

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