[jcifs] Property Inconsistencies (Davenport)

[Mike McDonald]

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

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

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.