STATUS_SHARING_VIOLATION for a folder rename

[vadimd02]

trafficstars

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 ?

[hierynomus]

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().

[hierynomus]

@vadimd02 Any update on this? Else I'll close it.

[vadimd02]

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

[hierynomus]

My guess is then that VFS2 does something wrong. You might want to check in their code why there is still a handle open.

[umjammer]

i had the same problem.

env is

• DOESN'T WORK engine: 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.

• WORKS engine: jcifs-ng 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,

https://github.com/AgNO3/jcifs-ng/blob/3db3e62157ce6eab2ab3719f63a53f25fd1231cb/src/main/java/jcifs/smb/SmbFile.java#L1359-L1361

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?

[dkocher]

Seems to work just fine with AccessMask.DELETE.

• [x] Windows 2016 Server 10.0.14393 SMB_3_1_1
• [x] Linux Samba SMB_3_1_1
• [x] macOS 13.5 (22G74) SMB_3_0_2

[umjammer]

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.

env

• smbj 0.12.2
• macos 13.5.2
• java -version

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)

• smb server macos 10.15.7 19H2026

conclusion

• this issue is not smbj fault
• one reason for STATUS_SHARING_VIOLATION is reopening a file
• commons-vfs2-smb has the bug above

---

thanks @dkocher and your code

[umjammer]

here is corrected commons-vfs2-smb works fine with smbj 0.12.2