Open vadimd02 opened 3 years ago
STATUS_SHARING_VIOLATION
means that the directory is still open somewhere. If you're using multiple threads, ensure that you do proper locking. Also use try-with-resources blocks to ensure you have not forgotten to call close()
.
@vadimd02 Any update on this? Else I'll close it.
Hi @hierynomus - smbj integrated with vfs2 library in my case , where I'm not manually handling the connection/close. All files/folders creation are limited as if I rename it once then this object cannot be modified later e.g. renamed/deleted. There is some case that after creation and then modification it can't be modified anymore where I'm getting the error that handler can't be created for this file/folder object
My guess is then that VFS2 does something wrong. You might want to check in their code why there is still a handle open.
i had the same problem.
env is
smbj 0.10.0
provider: commons-vfs2-smb 1.0.0-SNAPSHOT
vfs2: org.apache.commons:commons-vfs2:2.9.0
but the same test code using vfs2 api (wrapped by java nio file spi), it works using below env.
2.1.6
provider: commons-vfs2-cifs 1.2.0
(i modified it using jcifs-nj instead of jcifs)
vfs2: org.apache.commons:commons-vfs2:2.9.0
so this issue might be caused by smb PROVIDER
or smbj
not VFS2
.
my investigation so far,
renaming code of jcifs-ng
is like,
that sending FILE_WRITE_ATTRIBUTES
, DELETE
attributes for SET INFO
protocol.
and it works.
on the other hand smbj
renaming code, i couldn't find code setting attributes.
so i cannot try to set attribute.
this is current situation, what do you think about it?
Seems to work just fine with AccessMask.DELETE
.
SMB_3_1_1
SMB_3_1_1
SMB_3_0_2
my bad. i correct my previous post.
so this issue might be caused by smb PROVIDER or smbj not VFS2.
commons-vfs2-smb has a bug. the provider ends up not closing a file when uploading.
@@ -79,7 +81,9 @@ public class SmbFileObject extends AbstractFileObject<SmbFileSystem> {
@Override
protected OutputStream doGetOutputStream(final boolean append) throws Exception {
File file = smbTemplate.openFileForWrite(path);
- return file.getOutputStream(append);
+ return new FilterOutputStream(file.getOutputStream(append)) {
+ @Override public void close() throws IOException { super.close(); file.close(); }
+ };
}
@Override
and there are several corrections for commons-vfs2-smb. i will upload corrected commons-vfs2-smb to github in the near future.
java version "1.8.0_341"
Java(TM) SE Runtime Environment (build 1.8.0_341-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.341-b10, mixed mode)
STATUS_SHARING_VIOLATION
is reopening a filethanks @dkocher and your code
here is corrected commons-vfs2-smb works fine with smbj 0.12.2
Hi @hierynomus @pepijnve I'm using 0.5.1 version now where the issue also persist on 0.9.1 (this is a latest that working for me). Issue persist when creating a folder by thread A and after some time trying to rename a folder by thread B where folder created on a shared folder on a different machine. Creating a new folder AAA with this code:
DiskEntry de = diskShare.openDirectory(path, EnumSet.of(AccessMask.GENERIC_ALL), EnumSet.of(FileAttributes.FILE_ATTRIBUTE_NORMAL), EnumSet.of(SMB2ShareAccess.FILE_SHARE_READ), SMB2CreateDisposition.FILE_OPEN_IF, EnumSet.of(SMB2CreateOptions.FILE_DIRECTORY_FILE)); de.close();
When try to rename a folder then invoking same code without calling close to get a directory and failing with: com.hierynomus.mssmb2.SMBApiException: STATUS_SHARING_VIOLATION(3221225539/3221225539): Create failed for AAA
Can you please advise what are the difference same code working when creating and then modifying the folder on a "local" storage and same scenario on remote storage.
In addition - is this possible that application locking the new created folders and not closed all related handlers although close() is invoked ? Is there any way to check all un-released recourses ?