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
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.