Name mangling patch
fgouget at psn.net
Thu Mar 18 06:59:16 GMT 1999
Maybe we could use a third digit as a way to avoid clashes,
use two if everything is well and three if we detect a clash.
But let me restart from the beginning.
On Thu, 18 Mar 1999, Christopher R. Hertel wrote:
> Not really. His first patch fixes (I haven't checked it, but it's
> supposed to fix) that annoying problem I noticed but never tracked down,
> in which we were calling the mangling routines once too often.
I'm not sure it's related. One part was about avoiding to call
str_checksum twice *from* the name mangling. So unfortunately it's
> So, the clash-avoidance wouldn't slow us down any more than it does now.
> Remember, too, that we're in a splay tree so speed shouldn't be a problem.
> Thing is, and I have to check this, that the cache is there to allow
> bi-directional mangling, among other things. If we do clash avoidance,
> then the algorithm *must* be bi-directional and consistant.
> What if we have two names which mangle to the same thing (this is a very
> unreal example):
> Unix Name DOS (mangled) name
> name one.bugs name~.bxx
> name two.bugs name~.bxx
> Conflict. So, we detect the conflict and remangle the second name.
> Cool, no conflict. Except...
> Someone deletes the first file (either on the DOS or Unix side, doesn't
> matter). When we next visit the directory (i.e., no cache in use), the
> other file's mangled name will have changed! This is *no good*
> (particularly because the user will say "Oy! I thought I'd deleted that
> file! I'll just delete it again! Oy! Where's the other file?".
But is the current algorithm better ?
Let's say we have (to stick a little bit more to reality):
Unix Name DOS (mangled) name
name one.bugs name~aa.bug
name two.bugs name~aa.bug
I think that one of the problems that I'm having with 'del /s'
is the following:
1. del enumerates a directory contents and somehow builds a list. It
gets two entries called 'name~aa.bug'.
2. it deletes the first one, so far so good.
3. it deletes the second one but this fails because 'name~aa.bug'
still maps to 'name one.bugs' in the cache and this file has been
4. del stopped at point 3. but we directory is not empty so we would
not be able to delete it, potentially creating more problems.
It seems a bit odd to me that del builds a list of the files to
delete before doing so. Or there is something in Samba that makes it
look like it.
With the scheme I propose it should work like this:
1. del enumerates the directory. We return 'name~aa.bug' for 'name
2. we realize there is a clash for 'name two.bugs' and thus we return
'name~bb.bug'. Only there should we incur a performance penalty. Both
put in the mangled stack.
3. del deletes 'name~aa.bug', it's in the stack, no problem
4. del deletes 'name~bb.bug', it's in the stack, no problem
Now what happens if you try to map the mangled names back to the
Unix file when they are no longer in the mangled stack (assuming we did
not delete them):
1. open 'name~aa.bug', we have two files, which one should we open ?
We have no idea but this is nothing new. Take the first one or flip a
2. open 'name~bb.bug'. None of the Unix files mangle to this name. But
we found two files that mangle to a file of the form 'name~XX.bug'.
Maybe these are false matches. In this case either we refuse the partial
match, then mangled names resulting from cache avoidance can only be
used while in the mangle stack, or we accept the match which can lead to
the wrong file being open which is not worse than the current situation
except if the file that this referred to was deleted in the meantime.
Note that there's other solutions: increasing the base and the
number of digits. For the base we may gain one more value, '~'. It may
be nice especially since the user can choose what he wants to use for
this and he's likely to clash with one of our base characters. now if
clashes are fine it's good.
Maybe we could add one more digit: try 3 digits instead of two.
I understand that three digits means you only have 4 characters left for
the beginning of the name so maybe we could use the third digit only to
avoid clashes. This should avoid the last problem exposed above.
fgouget at multimania.com
More information about the samba-technical