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>
On Wed, Mar 20, 2024 at 06:18:59PM +0100, Ralph Boehme via samba wrote:>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! :)Renames are horribly tricky. It's only in the "destination file exists and overwrite flag is set" in the SMB2 case we have to fix I think. I've been looking at the logic here: 2.1.5.15.11 FileRenameInformation https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/87f86c9b-6c2a-4803-84b7-131a74a434fa It seems that in this specific case Windows deletes the target file first (see the bool variable 'RemoveTargetLink') although I'm presuming this is externally atomic to callers. Still thinking about how (or if) we could achieve the same..
20.03.2024 20:18, Ralph Boehme via samba:> 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.Why it is not possible? Second lock can't be done in waiting mode, it can only be done in lock-or-fail mode obviously (or else it is too prone to deadlocks). /mjt