The Samba-Bugzilla – Bug 1048
short name answer to FIND_FIRST2/FIND_NEXT2 wrong when mangled names = no
Last modified: 2005-08-24 10:16:07 UTC
smbd/trans2.c, function get_lanman2_dir_entry(), case
This function answers with a short name even when mangle_map() delivers only a
truncated name because of "mangled names = no". I.e. "reallylongname.txt"
becomes "REALLYLONGNA" (in Unicode). "REALLYLONGNA" ist nothing one will ever be
able to open, so it's simply false to answer with this name.
There ist at least one client which tries to use this wrong short name: NT4
SP6's Explorer when using drag'n'drop onto CMD files. Try this: Configure
mangled names = no, create some TEST.CMD with just one line 'COPY "%1" NUL',
then drag'n'drop a file with a long name onto TEST.CMD. It will answer with
"File not found", because it tries to copy "REALLYLO.NGN" instead of
In the case where the filename is not 8.3 and "mangled names = no" there simply
exists nothing like a valid short name and Samba should not try to invent one.
What I propose is to answer with an empty short name in this case. This seems to
be a perfectly vaild answer, Windows does this all the time when the file name
is already 8.3. I'll attach patches for 2.2.8a, 3.0.1 and 3.0.2pre1.
Created attachment 388 [details]
proposed patch for 3.0.2pre1
Created attachment 389 [details]
proposed patch for 3.0.1
Created attachment 390 [details]
proposed patch for 2.2.8a
Could you take a quick look at this one? Thanks.
Looks a good patch - applied for 3.0.3.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.