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

[Brian Bernstein]

It looks like the FILE_SHARE_DELETE flag is broken.

I just tried a much simpler case (I had not tested this case before as I
have had the FILE_SHARE_READ and FILE_SHARE_WRITE flags work properly
before).

In this case, I don't bother creating a resource in a new directory, I just
create a new file with all the share permissions, and then try to delete it
afterwards.  When this happens, I get the same error:

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)
     at jcifs.smb.SmbSession.send(SmbSession.java:239)
     at jcifs.smb.SmbTree.send(SmbTree.java:109)
     at jcifs.smb.SmbFile.send(SmbFile.java:695)
     at jcifs.smb.SmbFile.delete(SmbFile.java:2380)
     at jcifs.smb.SmbFile.delete(SmbFile.java:2324)

Also note that I am trying to implement a web interface for manipulating
SMB/CIFS repositories.  This is being deployed on a JBoss server.

I do not store SmbFile handles between requests.  As the delete is in a
successive request, I simply create a new SmbFile of that url, so I am
assuming that I am creating a new connection to that resource and am not
using the same connection as was used to create the resource initially.

Sorry for confusing the issue initially, I just never thought to have tried
this test initially.

I hope this helps in troubleshooting this.

-Brian

On 03/12/2007, Michael B Allen <miallen at ioplex.com> wrote:
>
> 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/
>
-------------- next part --------------
HTML attachment scrubbed and removed