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 leading periods. The problem was observed on a SPARC Solaris 9 system. I think that it is general though.
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() in smbd/mangle_hash.c. 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. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.