Discussion:
[jcifs] Acquiring exclusive lock on a file seems to not be working anymore
Dzhigarov. Marin
2016-08-08 13:50:25 UTC
Permalink
Hello all,

has anyone noticed that the SmbFile.FILE_NO_SHARE option which is supposed to grant an exclusive lock on a file, is not working anymore?
I wrote this small example program, which I run under windows 7 machine.
The program basically starts 45 threads which try to append the text “test\n” in the same file at the same time, incrementing a counter if a IOException “File used by another process” occurs.

At the end, it is expected to have the file text.txt containing N rows with the word “test”, and the number 45 – N printed in the console (the number of threads that got “File used by another process” exception).
However, the result is different on each execution and never correct – the number of rows containing “test” in the test.txt file plus the number printed in the console is always smaller than 45, which indicates that locking is not working at all.

public class CIFSTest {
private static final AtomicInteger i = new AtomicInteger(0);

public static void main(String[] args) throws MalformedURLException, SmbException, UnknownHostException, InterruptedException {
//LogStream.setLevel(4);
ExecutorService executor = Executors.newFixedThreadPool(45);
for (int i = 0; i < 45; i++) {
executor.submit(() -> {
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("SUB",
"test",
"test");

SmbFile f = null;
try {
f = new SmbFile("smb://localhost/CIFS/Test/test.txt", auth, SmbFile.FILE_NO_SHARE);
}
catch (Exception e) {}

int bytesRead = -1;
byte[] buffer = new byte[1000];
try (OutputStream out = new SmbFileOutputStream(f, true);
InputStream in = new ByteArrayInputStream("test\n".getBytes(StandardCharsets.UTF_8))) {
while ((bytesRead = in.read(buffer)) > 0) {
out.write(buffer, 0, bytesRead);
}
}
catch (IOException e) {
CIFSTest.i.incrementAndGet();
}
});
}

executor.shutdown();
executor.awaitTermination(20, TimeUnit.SECONDS);

System.out.println(i);
}
}

Or am I doing anything wrong?

Best regards,
Marin








SEEBURGER AG Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office: Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: ***@seeburger.de HRB 240708 Mannheim


Dieses E-Mail ist nur fÃŒr den EmpfÀnger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder MeinungsÀußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der EmpfÀnger, so haben Sie diese E-Mail irrtÃŒmlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Dzhigarov. Marin) ÃŒbernehmen die Haftung fÃŒr Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren AnhÀnge auf Viren zu prÃŒfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Dzhigarov. Marin) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
Moritz Bechler
2016-08-09 10:03:47 UTC
Permalink
Hi,
Post by Dzhigarov. Marin
has anyone noticed that the SmbFile.FILE_NO_SHARE option which is
supposed to grant an exclusive lock on a file, is not working anymore?
I wrote this small example program, which I run under windows 7 machine.
The program basically starts 45 threads which try to append the text
“test\n” in the same file at the same time, incrementing a counter if
a IOException “File used by another process” occurs.
At the end, it is expected to have the file text.txt containing N rows
with the word “test”, and the number 45 – N printed in the console
(the number of threads that got “File used by another process” exception).
However, the result is different on each execution and never correct –
the number of rows containing “test” in the test.txt file plus the
number printed in the console is always smaller than 45, which
indicates that locking is not working at all.
Yep, there is a bug - but it's not the locking that is broken, it's
SmbFileOutputStream's append mode. It does use
Trans2QueryFSInformationResponse to retrieve the current file length as
it calls SmbFile.length before opening it (which does not follow the
sharing semantics and probably has no consistency guarantees
whatsoever). Therefor your file pointer will be set to a stale position
and you do not actually append but overwrite already present data. Nice.

( Patch, which may or may not apply cleanly:
https://github.com/AgNO3/jcifs-ng/commit/022842a1685293335e918a2a1d5416cf39bccdd9
)

regards

Moritz
Michael B Allen
2016-08-10 03:47:03 UTC
Permalink
Post by Dzhigarov. Marin
Hi,
has anyone noticed that the SmbFile.FILE_NO_SHARE option which is supposed
to grant an exclusive lock on a file, is not working anymore?
I wrote this small example program, which I run under windows 7 machine.
The program basically starts 45 threads which try to append the text
“test\n” in the same file at the same time, incrementing a counter if a
IOException “File used by another process” occurs.
At the end, it is expected to have the file text.txt containing N rows with
the word “test”, and the number 45 – N printed in the console (the number of
threads that got “File used by another process” exception).
However, the result is different on each execution and never correct – the
number of rows containing “test” in the test.txt file plus the number
printed in the console is always smaller than 45, which indicates that
locking is not working at all.
Yep, there is a bug - but it's not the locking that is broken, it's
SmbFileOutputStream's append mode. It does use
Trans2QueryFSInformationResponse to retrieve the current file length as it
calls SmbFile.length before opening it (which does not follow the sharing
semantics and probably has no consistency guarantees whatsoever). Therefor
your file pointer will be set to a stale position and you do not actually
append but overwrite already present data. Nice.
https://github.com/AgNO3/jcifs-ng/commit/022842a1685293335e918a2a1d5416cf39bccdd9
)
Hi Moritz,

Thanks for finding this and sharing your fix. I have added this to the
TODO list. As usual no ETA for actually being applied.

Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Continue reading on narkive:
Loading...