Subject: Name mangling patch

From: Francois Gouget <[email-masked]>
Date: Sun, 14 Mar 1999 19:45:13 +1100

I started looking into problems I was having when doing a 'del
/s *.class'. Out of about 690 files about 190 were not correctly
deleted. So I started looking into 'smbd/mangle.c' and after a few hours
I realized it was all fixed in 2.0.3.

	Actually almost, I still had 2 files that did not delete
correctly because of clashes in the mangled name. To do the mangling
Samba uses a base 36 but there are other characters that are not mabgled
by Windows that we can use. The list I have found is the following:
"_-!@#$%" ('~' is not mangled either but I'm not sure we can use it).
Adding these means we use a base 43 which once squared translates into
the risk of clash being reduced by a factor of around 1.43. And for me
that solves it, I not longer get name clashes :-).
	This change is in 'diff1990313-mangle1.txt'.

	While I was poking in mangle.c I realized that in many cases
(every filename with a 3 character or less extension) we were mangling
the filename twice: once with the extension and once without. This
certainly does not affect performance much but still it bothered me so I
made up a patch to avoid this. 
	This change is in 'diff1990313-mangle2.txt'.

	Back to the subject of name mangling, would it be possible to
use the mangled name stack to avoid clashes ? I admit I am not sure how
much impact it would have but would the following scenario be possible ?

 * Building a mangled name
    - compute the filename hashcode (modulo MANGLE_BASE^2). Check in the
mangled stack whether there is already another file with that hash code
    - if no build the name and return it to whoever asked for it
    - if yes it means we have a clash. In that case change the hashcode
until it no longer clashes (e.g. increment or use more clever hashtable
techniques) 

 * Using the name
    - As long as you find the mangled name in the mangled stack
everything's fine. Note that in the stack you may have two long names
that would normally clash but we returned a modified name for one of
them just to avoid the clash. As long as this modified name is still in
the mangled stack we don't have any problem.
    - The angled name is not in the stack. I don't know what
currently happens in this case. I guess we can take all the files in
that directory and compute their mangled names. If we find one that
matches good. It may not be the right file but it would be no worse than
the current situation.
    - If no perfect match is found we could try to find files for which
everything but the mangling par matches, i.e. if we look for 'foo
f~sc.txt' and we find a 'foo file.txt' then that must be it. That is
unless it was a file we just deleted.

	Anyone care to comment on this ? Is there any major flaw in
this scheme ? Would anyone be interested to implement it (it may take
time before I get to it if at all) ?

--
Francois Gouget
[email-masked]