This is the content of a share: lrwxrwxrwx 1 bjacke users 6 30. Jun 12:25 YY -> YY.txt -rwxr--r-- 1 bjacke users 0 30. Jun 12:25 'YY (2)' Then I connect with smbclient...: smb: \test2\> dir . D 0 Fri Jun 30 12:55:15 2023 .. D 0 Fri Jun 30 11:40:43 2023 YY (2) A 0 Fri Jun 30 12:25:22 2023 256917828 blocks of size 1024. 82437832 blocks available okay, so far, this is expected because the symlink is dangling. But then: smb: \test2\> rename YY (2) YY NT_STATUS_OBJECT_NAME_NOT_FOUND renaming files \test2\YY -> \test2\(2) This is not expected. Tested the same with 4.16, there the rename operation is successfull and the dangling symlink is replaced by the rename operation.
Can you post your smb.conf so I know what the share definition looks like please ?
OK, reproduced this on a "normal" SMB2 share.
I'm leaning to thinking that 4.18 is doing the right thing and 4.16 is incorrect here. The object exists, even though we can't see it. A dangling symlink is similar to a vetoed file, in that it prevents operations on it. Let me see how we behave if the target is a vetoed file.
Yep, renaming a file on top of a vetod file return the same error: NT_STATUS_OBJECT_NAME_NOT_FOUND. I'd argue that we are at least consistent here now. Bjorn, can you discuss with Ralph and Metze to see if they agree with me ?
isn't the problem how we deal with dangling symlinks? If a dangling symlink on the server is not being listed but it causes errors and unexpected things to happen out of the blue from the client's perspective. Maybe we should not hide dangling symlinks but show it as a file with no read permissions instead? Just an idea. The current way how we handle dangling symlinks is far from ideal in any case I think.
*** Bug 15489 has been marked as a duplicate of this bug. ***