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
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
Created attachment 4526 [details]
Torture test to verify the fix
Created attachment 4527 [details]
Looks good to me - Volker, can you review and assign to Karolin for inclusion in 3.4.1 ? Thanks,
Pushed, will be included in 3.4.1.
Closing out bug report.