3121249243f52dcbf8083f5ff137bd580515efa7 allowed us to correctly handle renaming directories when a client has files open underneath it, but it also introduced a bug. If a client holds open a handle to the directory, and then tries to rename it, the rename should be allowed, but in 3.4.x the client will get NT_STATUS_ACCESS_DENIED. We have already seen a few instances of SMB clients doing this in the field, and customers seeing this seemingly random NT_STATUS_ACCESS_DENIED. The attached patches fix the problem against v3-4-test and add a regression test so it's not broken by any future patches. The fix is slightly different in 3.4 than it was for master due to the smb_filename changes.
Created attachment 4526 [details] Torture test to verify the fix
Created attachment 4527 [details] Fix
Looks good to me - Volker, can you review and assign to Karolin for inclusion in 3.4.1 ? Thanks, Jeremy.
Pushed, will be included in 3.4.1. Closing out bug report. Thanks!