When I use Windows Explorer to create a new folder (by right-clicking, going under New, and choosing Folder) on a network drive hosted by a Samba server, two new folders are created: "New Folder" and "New Folder (2)". This happen usually, but not always; I think that disconnecting the network drive, reconnecting, then waiting a minute or so before creating the folder is sufficient to make it happen. This is with a Windows XP SP2 client connected to Samba 3.0.25a running on CentOS 4.5. From what I can tell from looking at packet dumps and debug logs, I think that Samba may be sending invalid NOTIFY responses to the server. When the first "New Folder" is created, Samba sends two NOTIFY responses: one with the filename "New Folder" truncated, and one with NULL contents. Wireshark and the CIFS Technical Reference seem to say that the second NOTIFY shouldn't happen at all. After receiving the NOTIFY packets, the Windows client disconnects and reconnects (as error handling for the invalid NOTIFY?), does not request notification on the new connection, tries again to create "New Folder", is told there's a name collision, and so creates "New Folder (2)".
Created attachment 2749 [details] Wireshark dump of mapping a drive and creating "New Folder" and "New Folder (2)"
Created attachment 2750 [details] Level 10 debug log of mapping a drive and creating "New Folder" and "New Folder (2)"
I have a fix for this... give me an hour or so and I'll attach for testing. Jeremy.
Created attachment 2751 [details] Patch This will be in 3.0.25b - please test ! Thanks, Jeremy.
Thank you for the fast fix. It fixed the "New Folder (2)" error in testing, and I'll install it on our production servers tonight to make sure that it fixes the other client disconnects that we've been seeing. A question, if you don't mind: I checked the CIFS Technical Reference while trying to figure out this problem, and it made it sound like the MaxParameterCount field should limit the size of any notification messages, and from what I could tell from testing, it looks like Windows Server 2003 won't return a NOTIFY message with a buffer larger than MaxParameterCount. However, it looks like this patch ignores MaxParameterCount and may return a message of any size. Is MaxParameterCount not that important after all?
How did you test that the W2K server doesn't return a message greater than maxparametercount ? The XP client sends a maxparameter count of 32, which is obviously too small to be of use. None of our other code returning NTTrans params is restricted by maxparamcount so I align this with our existing practice. Jeremy.
When tested against 2K3, notify data for the creation of "New Folder" is 32 bytes exactly and is included in the notify message. Notify data for the creation of "New Folder (2)" is longer than 32 bytes, and the notify message sent when "New Folder (2)" is created is empty. But the longer messages returned by Samba don't seem to cause any problems for the XP client, and it makes sense to match Samba's existing practice, and 2K3's behavior doesn't seem to match the CIFS Technical Reference either (the Tech Ref says to send a status of STATUS_NOTIFY_ENUM_DIR if the notify data is too large for the buffer, but 2K3 apparently just sends STATUS_SUCCESS). So I'm not sure what all of that means, but it appears that either approach will work. And I know relatively little about CIFS, so I could easily be missing something. Thank you for your time.
A quick update: We've been running this patch for several days now on our production servers and have seen no further issues. Thank you for the fix!
Fixed for 3.0.25b. Jeremy.