So, what I did:
1. Mount samba share on windows
2. Mount the same samba share on linux (over localhost) on /mnt
3. Started an executable on windows (xml_upload.exe), so
that this file is busy/locked on the samba side.
4. Raised debugging to 8 and started tcpdump
5. On linux, did a plain mv:
mv /mnt/.rel/ekis0/xml_upload.exe.1 /mnt/.rel/ekis0/xml_upload.exe
6. stopped tcpdump and lowered debugging to 1.
This succeeded, despite /mnt/.rel/ekis0/xml_upload.exe is running on
windows client (from the same samba server) and is locked on samba
side, so it should fail.
The traces attached are from the operation #5.
Before someone else tells me I should not touch files on linux server
while they're used by samba: I AM NOT TOUCHING FILES BEHIND SAMBA'S
BACK.
I'm touching them THROUGH samba, by MOUNTING the *SAMBA* share on linux
and using that mount. Once again: I do it on linux THROUGH samba, NOT
behind samba.
It looks to me that while renaming a file, samba checks only if the SOURCE
file is locked, but not if the DESTINATION file is locked.
While at it, I also noticed another interesting tidbit, with removals:
1. Start the executable on windows
2. rm that executable file on linux (MOUNTED THROUGH SAMBA again).
the rm will hang.
3. Cancel the rm (hit Ctrl+C)
4. stop the executable on windows (started in 1.)
5. Notice the file is gone, despite the rm has been interrupted.
Another, more interesting scenario:
1. Start the executable in windows.
2. rm the executable on linux (though samba!!!)
the rm will hang
3. interrupt the rm
4. rename some other file with this name (which succeeds)
5. stop the executable on windows (started in 1.)
6. notice the file is gone, despite it is now the NEW file already, --
here, we have obvious data loss.
All this look Seriously Wrong (tm).
Thanks,
/mjt
On Tue, Mar 19, 2024 at 09:22:07AM +0300, Michael Tokarev via samba wrote:>So, what I did: > >1. Mount samba share on windows >2. Mount the same samba share on linux (over localhost) on /mnt >3. Started an executable on windows (xml_upload.exe), so > that this file is busy/locked on the samba side. >4. Raised debugging to 8 and started tcpdump >5. On linux, did a plain mv: > mv /mnt/.rel/ekis0/xml_upload.exe.1 /mnt/.rel/ekis0/xml_upload.exe >6. stopped tcpdump and lowered debugging to 1. > >This succeeded, despite /mnt/.rel/ekis0/xml_upload.exe is running on >windows client (from the same samba server) and is locked on samba >side, so it should fail. > >The traces attached are from the operation #5.Sorry Michael, traces are stipped from the mailing list I think. This is an excellent summary of the bug. Can you open a bug report in our bugzilla and use this text as the descriptor and add the traces there. The only thing that would be helpful would be the version of the Linux kernel being used in case we need the same version of the SMB2 client to reproduce (unlikely, but still good to know).>Before someone else tells me I should not touch files on linux server >while they're used by samba: I AM NOT TOUCHING FILES BEHIND SAMBA'S BACK. >I'm touching them THROUGH samba, by MOUNTING the *SAMBA* share on linux >and using that mount. Once again: I do it on linux THROUGH samba, NOT >behind samba.Fully understood, believe me :-).>It looks to me that while renaming a file, samba checks only if the SOURCE >file is locked, but not if the DESTINATION file is locked.This indeed looks to be the case, after at a quick glance at the code. Probably my fault, as I wrote the inital rename logic a *looong* time ago :-(. Thanks ! Jeremy.
On 3/19/24 07:22, Michael Tokarev via samba wrote:> It looks to me that while renaming a file, samba checks only if the SOURCE > file is locked, but not if the DESTINATION file is locked.d'oh! I completely missed that part... I guess the problem is that we can't lock two locking.tdb records simultaneously. We already have the source file record locked, also locking the the destination record is not possible. We could check the destination record without holding a lock *before* acquiring the lock on the source file record, but that would be a possible victim to races. It would be better then what we have now though I guess. Patches welcome! :) Cheers! -slow -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20240320/7cb4c53c/OpenPGP_signature.sig>