[jcifs] small caching bug with jcifs

Michael B Allen ioplex at gmail.com
Thu Jun 4 23:57:03 GMT 2009


On Thu, Jun 4, 2009 at 1:02 PM, Thomas Fromm <tf at inubit.com> wrote:
> Hi,
>
> I wasn't able to find the link to your bug tracking tool at your homepage :-/.
> (Is there one?)
>
> So I decided to post it here.
>
> I recognized, that the length and maybe also the lastModified values of a
> SmbFile are not updated, after using an (appending) output stream.
>
> e.g.:
> SmbFile file=new SmbFile("smb://...");
>
> OutputStream os=new SmbFileOutputStream(file);
> os.write(0);
> os.close();
>
> // at this point, the file.length() is '1'
>
> // now append data
> os=new SmbFileOutputStream(file, true);
> os.write(data);
> os.close();
>
> // now the file.length() is still '1' but should be '2'

You have to create a separate SmbFile instance after you close the
first stream. Then it will work.

Or you can set jcifs.smb.client.attrExpirationPeriod to 0 but that can
make many operations much slower.

> Maybe you can update the size member of the SmbFile object during or at the
> end of the writeDirect, or reset the expire time of it.

I'm not sure that is a good idea. Trying to reach over and update
things like that is a little sketchy (e.g. do we also update
lastModified?). I think it would actually work in this particular case
and I have added it to the TODO for further consideration but I'm not
going to look at this right now.

Note that SmbFile objects as immutable. So if you create two separate
instances and set data through one, it will not (immediately) be
reflected in the other. You have to create the first, do the
operation, then create the second and then the second instance will
see the change. There are quite a few attributes of files that behave
this way. I'm pretty sure this is discussed in the documentation
somewhere.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/


More information about the jcifs mailing list