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

Michael B Allen miallen at ioplex.com
Wed Apr 2 14:15:43 GMT 2008


On Wed, 2 Apr 2008 09:43:34 -0400
"Brian Bernstein" <brian.bernstein at indorse-tech.com> wrote:

> I think I've finally gotten to the bottom of this issue.
> 
> It appears the issue is not in the share permissions or the
> FILE_SHARE_DELETE flag, but rather in the manner that JCIFS goes about
> deleting files.
> 
> JCIFS attempts to delete a file via a SmbComDelete.  However, it was
> noticed that other clients go about deleting files differently. . . by
> opening them up, calling a SetFileInformation with the
> SetDeleteOnClose flag, then closing them afterwards.  It apears that
> windows will honor the FILE_SHARE_DELETE flag only when deleting in
> this way and will still return a "in use by another process" error if
> deleting in the way that JCIFS does with the SmbComDelete command.

Interesting. I never noticed that (probably because it was all
written in the NT 4.0 days).

> I have patched my copy of JCIFS to try SmbComDelete, and then go about
> doing it the latter way if it gets the "in user by another process"
> error.  So far, it appears to be working as expected.  I will continue
> some more testing and then send in a patch which I hope will be
> included into the next release.
> 
> -Brian
> 
> On 03/12/2007, Brian Bernstein <brian.bernstein at indorse-tech.com> wrote:
> > 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/
> > >
> >
> 
> 
> -- 
> ======================================
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
> 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
> 


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


More information about the jcifs mailing list