Created attachment 16256 [details] Wireshark trace file When SMB2 Find Response contains a 'FileIdBothDirectoryInfo' which is empty (ie. Filename length: 0) then the Linux Samba Client reacts with # ls /media/cifs/dite/ -rlt ls: reading directory '/media/cifs/dite/': Input/output error total 0 The Windows 10 (Samba) Client still manages to enumerate directories with this protocol interaction. Attached please find: SAMBA_Linux_Access_Problem.pcap - Wireshark trace of the interaction (see Frame 25) Wireshark_extract_Samba_Zombie_file.pdf - Extract of part of the above Frame showing the issue (hopefully).
Created attachment 16257 [details] PDF Extract from Wireshark trace file
Chaning to product to cifs vfs as this seems to be a bug with the Linux kernel SMB client.
file name length of 0 looks very weird. I think you forgot to mention the important point that you are using a OpenVMS port of Samba, don't you? Is there any point in listing a file that has 0 file name lenght? It would be interesting if the the protocol specs say anything about such a weird case also.
(In reply to Björn Jacke from comment #3) ah, you mentioned openvms in the subject, sorry :-)
https://docs.microsoft.com/de-de/openspecs/windows_protocols/ms-fscc/2917da5c-253c-4c0e-aaf6-9dddc37d2e6e 2.1.5.2 Filename A filename MUST be at least one character but no more than 255 characters in length. Also if Windows 10 ignores such an illegal file with 0 character filename length, I'm not sure if this is better than returning an I/O error in that case. I tend to say, the I/O error is the better choice. You should get the people doing that samba port to fix it.
So to be precise: "DIR" on Windows skips the corrupted (zero length filename) entry in the query directory results, but does not return an error to the user? That could be a Windows client bug or it could be preferred behavior - there are tradeoffs.
On create, presumably open means the root of the share so this presumably is a server bug.
(In reply to Steve French from comment #7) typo above: On create, empty filename (length 0) means the root of the share so this presumably is a server bug if it is allowing it in query dir response. The "MUST" in the spec indicates that server can not return it. Sounds like Linux client behavior is reasonable returning an error. Any idea how anyone could ever get Samba to return 0 length filename?
It's not a 100% clear for me. If "filename MUST be at least one character but no more than 255 characters in length" why does it not lead to a protocol violation on the part of the Linux Client SMB state M/C. I don't see that in my Wireshark trace.
RE: Comment 8. On OpenVMS it is very easy to create a "." file. $ CREATE . CTRL^Z It is most probably an application such as DECwindows that is causing such a behaviour of leaving "." files.