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

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Suresh Yellamaraju [SMTP:syellam at yahoo.com]
> 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.
> 
	So you're using SmbFile.FILE_NO_SHARE as a share access parameter
	to SmbFile (or at least not specifying FILE_SHARE_DELETE)? It sounds
	like it's not really being closed so it just sits open until
	jcifs.smb.client.soTimeout expries and shuts down the transport.

> (1) How is it that the close then can complete its
> call and return?
> 
	If you call close and it returns the file should really be closed. It cannot
	return before that unless there is an error.

> (2) Is there a way of knowing, if the file is in use
> by another process?
> 
	Yes. Create an SmbFile with the FILE_NO_SHARE access parameters
	and then use that file to create an SmbFileOutputStream. If the file is
	being accessed by another process you will get the said exception.

	I tried to reproduce this problem without success. I wrote a 30MB file and
	deleted it immediately after closing it. It worked fine. Check to make sure
	you are really closing the stream that opened the file with
	FILE_NO_SHARE. Otherwise, the quickest way to determine what the
	problem is is to get a packet capture with Ethereal or NetMon. You can
	send that to me directly.

	Mike