Open johannes-martin opened 5 years ago
It looks like explicitely closing the files after closing the input streams does not solve the problem.
Further note: it looks like - even if I explicitely close the files - they do not actually get closed. An attempt to move a previously opened file on the command line while the Java program is still running fails saying that the resource is busy.
Sorry for the delay.
It is no longer necessary to close the SmbFile in regular mode of operation (some info at https://github.com/AgNO3/jcifs-ng#jcifs-ng-16-unreleased). The "unshared" mode is only for specific situations in strictResourceLifecycle mode (which I would not recommend to use as the benefits are minimal).
However, now you have to make absolutely sure that you properly close Input and OutputStreams, RandomAccessFile, iterators and other returned handles. My best guess would be that you are missing a close call somewhere.
I recently encountered this failure, and the stacktrace led me to SmbFile[] files = SmbFile.listFiles
where I did not call close
on the returned arrays single SmbFile objects. I'm not yet sure that this may have been the cause, but it seems like a valid reason.
I upgraded a couple of programs from jcifs-ng 1.5.3 to 2.0.8.
The clients now connect using SMBv2 (using jcifs.smb.client.disableSMB1=true) and usually work fine.
In some cases they fail with the above mentioned exception when trying to open an input stream for a file or when trying to rename a file. In all cases, it was previously (in the same VM) possible to obtain input streams for other SMB files without problems.
When the client runs ok, I see a number of messages like "File handle was not properly closed: FileHandle <path & name of the file>".
The clients close any input streams obtained. I reviewed the source for SmbFileInputStream and saw that its close() method only closes the SMB files for "unshared" input streams. I failed to find any code that actually returns an input stream in "unshared" mode.
Questions: