[jcifs] Help - issue with close() on smbFileOutputStream

[Dan Dumont]

This is probably the result of the file attributes being cached.  There is a
setting that will tell the class how long to keep information about a file



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.

-----Original Message-----
From: jcifs-bounces+dan=canofsleep.com at lists.samba.org
[mailto:jcifs-bounces+dan=canofsleep.com at lists.samba.org] On Behalf Of
Suresh Yellamaraju
Sent: Wednesday, June 18, 2003 9:51 AM
To: jcifs at lists.samba.org
Subject: [jcifs] Help - issue with close() on smbFileOutputStream

Hi
After writing the file, I call the close on
SMBFileOutputStream. I attempt deleting the file
immediately after the close call returns. This gives
me the file is in use by another process. Looks like
the file is still being written to. This happens if a
large file is written. It takes close to 10-20 seconds
before deletion is allowed.
(1) How is it that the close then can complete its
call and return?
(2) Is there a way of knowing, if the file is in use
by another process?

Thanks in advance for your help
Suresh

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com