Windows 9x and Me use the old RAP calls. In particular, they use NetShareEnum() RAP call to retrieve share names. NetShareEnum() has a built-in share name limit of 12 bytes. If you send a NetShareEnum() request to a W2K server that has a share named "verylongsharename" that share won't be listed. What I'm seeing from the latest CVS is that the name "verylongshare" is returned and displayed (by W98 in this case). There are two problems with the above name: 1) It's truncated, so it's not the correct share name and the share cannot be accessed. 2) It's 13 characters. That means that we're not terminating the string. No terminating nul byte! Testing against W2K I confirmed that it won't return share names longer than 12 bytes (not even names that are exactly 13 bytes), and the names that are returned are always nul-terminated. So, somewhere in lanman.c (need to look a little closer) we need to be checking the name length and skipping the name if it's longer than 12 bytes.
The fix I've applied to HEAD is based on Simo's patch, which skips any name longer than 12 bytes. This is compatible with what Windows does. A better fix would be to do a simple name mangling (*not* based on existing mangling code) to create 12-character names from long share names, and store both. Return the long name in response to the RPC call, and return the short name in response to the RAP call. I want a simpler mangling algorithm because I'd like to preserve as much of the original name as possible. So, something like this, perhaps: AVERYLONGSHARENAME1 ==> AVERYLONGS~0 AVERYLONGSHARENAME2 ==> AVERYLONGS~1 AVERYLONGSHARENAMETHINGY ==> AVERYLONGS~2 : : AVERYLONGSHARENAMEYETAGAIN ==> AVERYLONG~10 etc., using a minimum of hex digits for the part after the tilde. ...just a thinkling.
Jeremy merged the changes into 3.0.
Closing this one out.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.