[jcifs] Property Inconsistencies (Davenport)
Mike.McDonald at anywaregroup.com
Mon Feb 9 23:57:17 GMT 2004
> > 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
Sorry for the ambiguity. What I meant was that the getlastmodified and
creationdate elements are populated via a call to SmbFile.lastModified(). The
date calculated is 'Thu, 01 Jan 1970 00:00:00 GMT', meaning that the function
did in fact return 0 when called on a 'share' (as you noted). It does in fact
return a proper date when called on a directory (as expected)
> > 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?
When I call SmbFile.length() on the share, it returns 98626961408 (in this
case). When I call it on a directory, it returns 0.
I have experienced the problem on SAMBA, Windows 2000, and Windows XP SMB
servers. I am running a Windows XP client, IE 6.0 with all Windows Updates
applied. I have been running the Davenport Servlet on both Windows 2000
Professional (fully patched) and on RedHat 9. I have been using Java 1.4.2_03
It appears that I can likely fix this problem (as suggested by Julian) by not
returning bogus dates and returning 0 for the getcontentlength property. I'll
try that and will keep you posted.
Thank you all for your help.
More information about the jcifs