[jcifs] Getting concurrency error when deleting a file

Post by Hugo Palma
Hi all,
a have a very simple use case where i want to get all the file in a
directory, iterate over them a delete a few.
SmbFile folder = new SmbFile("smb://myfolder");
for (SmbFile file : folder.listFiles()) {
// do something
file.delete();
}
It seems that if that "do something" doesn't include calling the
"getInputStream" method on the file everything goes fine. But if it does i

I would think that that should still work since I thought
getInputStream opened the file with a permissible shareAccess. Perhaps
not.

Anyway, try calling close() on the InputStream before you delete().

Mike

Post by Hugo Palma
jcifs.smb.SmbException: The process cannot access the file because it is
being used by another process.
        at
jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:522)
        at
jcifs.smb.SmbTransport.send(SmbTransport.java:622)
        at
jcifs.smb.SmbSession.send(SmbSession.java:239)
        at
jcifs.smb.SmbTree.send(SmbTree.java:109)
        at
jcifs.smb.SmbFile.send(SmbFile.java:718)
        at
jcifs.smb.SmbFile.delete(SmbFile.java:2342)
        at jcifs.smb.SmbFile.delete(SmbFile.java:2286)
Any idea why this is happening ? Clearly some resource if being left open
but i don't see any close method.
Thanks

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Hugo Palma

2009-03-03 09:50:21 UTC

Thanks for the tip. Got me thinking about the permissions and i solved it by
changing my code to:

SmbFile folder = new SmbFile("smb://myfolder");
for (String filePath : folder.list()) {
SmbFile file = new SmbFile(folder.getPath() + filePath, null,
SmbFile.FILE_SHARE_DELETE);

// do something

file.delete();
}

i
I would think that that should still work since I thought
getInputStream opened the file with a permissible shareAccess. Perhaps
not.
Anyway, try calling close() on the InputStream before you delete().
Mike
- Show quoted text -

Post by Hugo Palma
jcifs.smb.SmbException: The process cannot access the file because it is
being used by another process.
at
jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:522)
at
jcifs.smb.SmbTransport.send(SmbTransport.java:622)
at
jcifs.smb.SmbSession.send(SmbSession.java:239)
at
jcifs.smb.SmbTree.send(SmbTree.java:109)
at
jcifs.smb.SmbFile.send(SmbFile.java:718)
at
jcifs.smb.SmbFile.delete(SmbFile.java:2342)
at jcifs.smb.SmbFile.delete(SmbFile.java:2286)
Any idea why this is happening ? Clearly some resource if being left open
but i don't see any close method.
Thanks

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Michael B Allen

2009-03-03 16:15:18 UTC

Post by Hugo Palma
Thanks for the tip. Got me thinking about the permissions and i solved it by
SmbFile folder = new SmbFile("smb://myfolder");
for (String filePath : folder.list()) {
     SmbFile file = new SmbFile(folder.getPath() + filePath, null,
SmbFile.FILE_SHARE_DELETE);
     // do something
    file.delete();
}

This does not make sense. The default shareAccess value is
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE which means
other clients should be premitted to perform all of those operations.

Did you previously supply a shareAccess parameter value of 0 by accident?

If not, I will have to spend time investigating this issue.

Mike

I would think that that should still work since I thought
getInputStream opened the file with a permissible shareAccess. Perhaps
not.
Anyway, try calling close() on the InputStream before you delete().
Mike
- Show quoted text -

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Hugo Palma

2009-03-03 16:18:41 UTC

No i didn't, i didn't even know what shareAccess was :o)
I posted all the code that creates sbmFiles so you can see that i
didn't supply any access properties.

This does not make sense. The default shareAccess value is
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE which means
other clients should be premitted to perform all of those operations.
Did you previously supply a shareAccess parameter value of 0 by accident?
If not, I will have to spend time investigating this issue.
Mike

I would think that that should still work since I thought
getInputStream opened the file with a permissible shareAccess. Perhaps
not.
Anyway, try calling close() on the InputStream before you delete().
Mike
- Show quoted text -

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Michael B Allen

2009-03-03 16:23:02 UTC

Post by Hugo Palma
No i didn't, i didn't even know what shareAccess was :o)
I posted all the code that creates sbmFiles so you can see that i
didn't supply any access properties.

Ok. I have added this to the TODO for further investigation. Perhaps
JCIFS is somehow opening files without the right shareAccess value.

Mike

This does not make sense. The default shareAccess value is
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE which means
other clients should be premitted to perform all of those operations.
Did you previously supply a shareAccess parameter value of 0 by accident?
If not, I will have to spend time investigating this issue.
Mike

I would think that that should still work since I thought
getInputStream opened the file with a permissible shareAccess. Perhaps
not.
Anyway, try calling close() on the InputStream before you delete().
Mike
- Show quoted text -

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Michael B Allen

2009-05-16 01:57:16 UTC