[jcifs] Timestamp not appearing to change after writing file

[Michael B Allen]

On Mon, 5 May 2003 10:27:12 -0600
"Barry Roberts" <blroberts at xactware.com> wrote:

> I have an application that was using mostly java.io.File's but is now
> using SmbFile's and SmbIn/OutputStreams.  The problem I'm seeing now
> is that the application writes out a file, then immediately checks the
> timestamp of the just-written file.  I have inserted code, to see what's
> going on, and after over-writing the old file, the new time stamp doesn't
> show up immediately.  By the time I can do an 'ls' on the Samba server,
> it's there, but the code always gets the lastModified time of the file
> it just overwrote, not something very close to the current time.
> 
> This was working over NFS mounts, but doesn't seem to work now with
> jCIFS to Samba on Linux.
> 
> Does anybody have any idea if there's some Samba setting or jCIFS
> tweak I could use to get this to work as it used to?

>From the 'Setting Client Properties' section in the API documentation:

  jcifs.smb.client.attrExpirationPeriod
  
  Attributes of a file are cached for attrExpirationPeriod milliseconds. The
  default is 5000. This greatly improves performance because it eliminates
  redundant calls to the server however it is possible that two separate
  instances of SmbFiles pointing to the same resource may produce
  different results in awkward situations (e.g. s1.canRead() may return
  true even though s2.delete() was called immediately before). For maximum
  reliability, turn off attribute expiration by setting this property to 0.

So if you set this property to 0 your problem should go away. But if
you are doing a lot of listing and checking attributes 2 minutes later
the client will become noticably slower.

Having said that, this is actually a bug. It was always assumed that
two different instances of SmbFiles would be necessary to see stale
attributes. I did not consider your case. I will fix this in the next
release. All I need to do is:

  attrExpiration = sizeExpiration = 0;

in SmbFileOutputStream.write(). See if the property change solves your
problem for now though. I don't feel like doing a release just for this.

Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.