[jcifs] Trouble deleting directory-- receive error message "The process cannot access the file because it is being used by another process."

[Michael B Allen]

On Mon, 3 Dec 2007 12:01:30 -0500
"Brian Bernstein" <brian.bernstein at indorse-tech.com> wrote:

> I am having trouble deleting a directory with contents within it
> shortly after creating said directory.
> 
> Here's what I do to receive this error:
> First, I create a directory on a resource, with full share permissions.
> SmbFile file = new SmbFile(dirUrl, credentials,
> SmbFile.FILE_SHARE_READ|SmbFile.FILE_SHARE_WRITE|SmbFile.FILE_SHARE_DELETE);
> file.mkDir();
> 
> Then I place files within this directory.
> SmbFile file = new SmbFile(dirUrl/fileName, credentials,
> SmbFile.FILE_SHARE_READ|SmbFile.FILE_SHARE_WRITE|SmbFile.FILE_SHARE_DELETE);
> file.getOutputStream.write(fileContents);
> 
> (this step can be repeated a few times).
> 
> Lastly, I try to delete the directory, however the original SmbFile
> reference has since been lost, so a new connection is made.

Hi Brian,

That should not happen. Connections are reused (unless you're using a
special class loader - like in a web server).

> SmbFile file = new SmbFile(dirUrl, credentials,
> SmbFile.FILE_SHARE_READ|SmbFile.FILE_SHARE_WRITE|SmbFile.FILE_SHARE_DELETE);
> file.delete();
> 
> However, the deletion fails and instead I get this exception:
> jcifs.smb.SmbException: The process cannot access the file because it
> is being used by another process.
>  	at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:514)
>  	at jcifs.smb.SmbTransport.send(SmbTransport.java:614)

If all of the files are opened with
SmbFile.FILE_SHARE_READ|SmbFile.FILE_SHARE_WRITE|SmbFile.FILE_SHARE_DELETE
the above error should not happen. Sounds like a bug (somewhere).

> First off, I was under the impression that if I open these resources
> with full share permissions
> (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE) that I would not
> be having these issues (isn't that what the FILE_SHARE_DELETE
> permissions is for?).

True.

> Do these permissions not apply towards
> directories or do not work when recursing?

An mkdir doesn't create a file handle so the shareAccess parameter should
not be applicable.

> I believe this issue is a timeout issue.  If the original socket(s)
> are allowed to timeout before the attempt is made, the delete works
> without an issue, however this timeout appears to be on the magnitude
> of minutes, which is too long.

This is somewhat moot in light of previous errors.

> 
> I had attempted to override this with the setConnectTimeout() but
> found it quite difficult to find an appropriate value to set this to
> as setting it too low would cause problems when trying to write to the
> connection.
> 
> Is there a way to perform an explicit disconnect when done with the connection?

No. There should be no reason to explicitly disconnect a connection. One
time someone came up with a valid (albeit exotic) reason but this case
is not.

Do you use SmbFileOutputStream? That class also accepts shareAccess flags.

Otherwise, the only way to fix this would be to get a capture of a minimal
sequence and determine what handle is responsible. First thing to do
is to look at the shareAccess flags in WireShark and make sure they're
right. I've messed around with those flags a few times over the years.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/