I've just upgraded a Samba 2.2.8a file server to Samba 3.0.9. I planned my
transition carefully and added "mangling method = hash" to the smb.conf, so that
existing mangled names stored on clients would remain valid.
I've noticed that when a long filename capable client lists the contents of a
directory, any files with Unix filename starting with a period character are
returned in their mangled 8.3 form. So, for example, ".profile" is listed as
"PROFI~M#.___", whereas both Samba 3.0.9 with mangling method hash2 and Samba
2.2.8a with mangling method hash will return ".profile" as a long filename (and
clients seem happy with such names).
This comes about because in 3.0.9 smbd/mangle_hash.c:name_map() checks the name
is with "is_valid_name()" and forces "need83 = True" if this check fails.
is_valid_name() explicitly checks for names that begin with a period character
and returns NT_STATUS_UNSUCCESSFUL for such names.
The corresponding check in 3.0.9 smbd/mangle_hash2.c:name_map() and 2.2.8a
smbd/mangle_hash.c:name_map_mangle() are less stringent - they both call
functions which check for illegal characters and *trailing* periods, but not
The problem was observed on a SPARC Solaris 9 system. I think that it is general
Created attachment 1008 [details]
unidiff for removing the troublesome code from mangle_hash.c
This patch removes the test for a leading period from function is_valid_name()
is_valid_name() is a static function that is only called in two places: once by
name_map() and once by is_8_3_w(). In the first case the leading period test
causes bug 2152 (unwanted and unnecessary name mangling is applied to a long
filename which starts with a period). In the second case the leading period
test is redundant: is_8_3_w() breaks an 8.3 name down into "prefix" and
"extension", and rejects as invalid names that have a zero-length prefix (if
statement at line 266).
this looks reasonable to me, shouldn't this be checked in ?
Jeremy, mind deciding what to do with this patch?
Actually, this test is an optimization put in the wrong place. I've moved it
into is_8_3_w() instead which is where it should have been.
Thanks, sorry this didn't make 3.0.20 - it'll definately be in 3.0.21.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.