Samba 3.0, debian package. Somewhere on the way between 2.x and 3.0 the default for 'mangling method' has been changed from 'hash' to 'hash2'. This works as it should (but makes mangled filenames practically unreadable). When one changes the setting to 'hash' though, using 'mangling method = hash', smbd appears to treat space (0x20) as an invalid character and mangles all the filenames containing it. This seems not to depend on the character sets used or on presence (or not) of valid.dat file. Example: beta:/home/shares/krakow/brixi# ls -al | grep V drwxrws--- 2 link link 4096 Feb 24 2003 Virtual PC 1) mangling method = hash2 (current default) smb: \brixi\> dir v* Virtual PC D 0 Mon Feb 24 08:34:19 2003 [2003/10/10 14:59:45, 8, pid=32077] smbd/trans2.c:get_lanman2_dir_entry(521) get_lanman2_dir_entry:readdir on dirptr 0x82c7418 now at offset 6 [2003/10/10 14:59:45, 10, pid=32077] lib/ms_fnmatch.c:ms_fnmatch(240) ms_fnmatch(v*,Virtual PC) -> 0 [2003/10/10 14:59:45, 8, pid=32077] smbd/dosmode.c:dos_mode(122) dos_mode: brixi/Virtual PC [2003/10/10 14:59:45, 8, pid=32077] lib/util.c:is_in_path(1473) is_in_path: brixi/Virtual PC [2003/10/10 14:59:45, 8, pid=32077] lib/util.c:is_in_path(1477) is_in_path: no name list. [2003/10/10 14:59:45, 8, pid=32077] smbd/dosmode.c:dos_mode(168) dos_mode returning d [2003/10/10 14:59:45, 5, pid=32077] smbd/trans2.c:get_lanman2_dir_entry(606) get_lanman2_dir_entry found brixi/Virtual PC fname=Virtual PC [2003/10/10 14:59:45, 10, pid=32077] smbd/mangle_hash2.c:name_map(612) name_map: Virtual PC -> 64AEEBD9 -> VRXP3O~9 (cache=1) [2003/10/10 14:59:45, 8, pid=32077] smbd/trans2.c:get_lanman2_dir_entry(521) get_lanman2_dir_entry:readdir on dirptr 0x82c7418 now at offset 7 2) mangling method = hash (old default) smb: \brixi\> dir v* VIRTU~IY D 0 Mon Feb 24 08:34:19 2003 [2003/10/10 15:00:09, 8, pid=32103] smbd/trans2.c:get_lanman2_dir_entry(521) get_lanman2_dir_entry:readdir on dirptr 0x8298ce0 now at offset 6 [2003/10/10 15:00:09, 10, pid=32103] lib/ms_fnmatch.c:ms_fnmatch(240) ms_fnmatch(v*,Virtual PC) -> 0 [2003/10/10 15:00:09, 8, pid=32103] smbd/dosmode.c:dos_mode(122) dos_mode: brixi/Virtual PC [2003/10/10 15:00:09, 8, pid=32103] lib/util.c:is_in_path(1473) is_in_path: brixi/Virtual PC [2003/10/10 15:00:09, 8, pid=32103] lib/util.c:is_in_path(1477) is_in_path: no name list. [2003/10/10 15:00:09, 8, pid=32103] smbd/dosmode.c:dos_mode(168) dos_mode returning d [2003/10/10 15:00:09, 5, pid=32103] smbd/trans2.c:get_lanman2_dir_entry(606) get_lanman2_dir_entry found brixi/Virtual PC fname=Virtual PC [2003/10/10 15:00:09, 5, pid=32103] smbd/mangle_hash.c:name_map(733) name_map( Virtual PC, need83 = False, cache83 = True) [2003/10/10 15:00:09, 5, pid=32103] smbd/mangle_hash.c:name_map(759) name_map() ==> [VIRTU~IY] [2003/10/10 15:00:09, 8, pid=32103] smbd/trans2.c:get_lanman2_dir_entry(521) get_lanman2_dir_entry:readdir on dirptr 0x8298ce0 now at offset 7 Regards, -- Lukasz Grochal
OK, so I'll scratch my itch myself: mangle_hash.c - name_map calls is_valid_name (line 740), apparently to check if the name is legal in the Windows 'long name' sense (not COMx, LPT, no backslashes etc. in it, not beginning or ending with '.'). But... - is_valid_name (unlike is_legal_name in hash2) is much more strict (it has to be, it is also called by is_8_3_w), it calls has_valid_chars (line 219), which, in turn, calls isvalid83_w (line 153) which... yes, decides that the filename needs mangling. I guess the easiest way will be to just get is_legal_name from hash2, put it in hash and call it from name_map directly, just as in hash2. BTW, wouldn't it be easier (to maintain) if mangle_hash.c was simply a copy of mangle_hash2.c modulo the mangling/mangled name detection portions? The former looks much cleaner with much less what I guess is junk from old, not UNICODE clean codebase. Regards, -- Lukasz Grochal
*** This bug has been marked as a duplicate of 2769 ***