Using the cifs version from the 2.6.20.4 kernel and a 3.0.24 samba server, linux extensions enabled on both ends as far as I can tell, the following python code: import fcntl open('bork', 'w').write('borkborkbork') fro = open('bork', 'rb') frw = open('bork', 'rb+') fcntl.lockf(frw, fcntl.LOCK_SH) frw.write('lalala') frw.truncate() frw.close() fro.close() runs "successfully" and leaves "borkbo" in the file: the truncate succeeded but the write before it did not actually change the file. If oplocks are disabled on the server the second fd ("fro") is not necessary to trigger the bug. If an "exclusive" lock (LOCK_EX instead of LOCK_SH) is used it works (leaves "lalala" in the file). dmesg on the client has "CIFS VFS: Write2 ret -13, written = 0". Possibly relevant lines in the server log (I'll attach a more complete log snippet) include: [2007/03/29 00:32:00, 3] smbd/process.c:switch_message(914) switch message SMBwriteX (pid 2769) conn 0x803defa0 [2007/03/29 00:32:00, 4] smbd/uid.c:change_to_user(170) change_to_user: Skipping user change - already user [2007/03/29 00:32:00, 3] smbd/error.c:error_packet(146) error packet at smbd/reply.c(3098) cmd=47 (SMBwriteX) NT_STATUS_FILE_LOCK_CONF LICT and [2007/03/29 00:32:00, 3] smbd/process.c:switch_message(914) switch message SMBtrans2 (pid 2769) conn 0x803defa0 [2007/03/29 00:32:00, 4] smbd/uid.c:change_to_user(170) change_to_user: Skipping user change - already user [2007/03/29 00:32:00, 3] smbd/trans2.c:call_trans2setfilepathinfo(3850) call_trans2setfilepathinfo(8) bork (fnum 11976) info_level=1020 totdata=8 so as far as I can tell the attempt to write triggers an explicit locking check inside samba, while the truncate does not trigger such a check and there is no underlying fs lock stopping the truncate. I'm not sure if this is a server bug, a client bug or both. It looks like the client is not dealing with the server rejecting the write request gracefully (no error reported to userspace) but I'm not sure if the server is supposed to deny the write and/or truncate or not. If more information or a way to reproduce this without using python are needed please ask.
Created attachment 2354 [details] part of the server log
Yes, can you provide a testcase (that can be used without using python) to reproduce this problem?
This works as expected with LOCK_SH. I just ran this script as and the file is left with 'lalala' cat /tmp/test.py #!/usr/bin/env python import sys import fcntl open('bork', 'w').write('borkborkbork') fro = open('bork', 'rb') frw = open('bork', 'rb+') fcntl.lockf(frw, fcntl.LOCK_SH) frw.write('lalala') frw.truncate() frw.close() fro.close() /mnt/smb_b # more bork lalala
Seems like it works based on descriptions below - if that is not the case re-open.