Bug 601 - setting 'mangling method = hash' causes ' ' (space) to be treated as illegal character
setting 'mangling method = hash' causes ' ' (space) to be treated as illegal ...
Status: RESOLVED DUPLICATE of bug 2769
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.0
All other
: P3 normal
: none
Assigned To: Samba Bugzilla Account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-10 06:07 UTC by Lukasz Grochal
Modified: 2005-09-29 05:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukasz Grochal 2003-10-10 06:07:51 UTC
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
Comment 1 Lukasz Grochal 2003-10-12 16:23:27 UTC
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
Comment 2 Gerald (Jerry) Carter 2005-09-29 05:37:36 UTC

*** This bug has been marked as a duplicate of 2769 ***