[Samba] renaming over to a busy file: traces

[Jeremy Allison]

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.