> Tren Blackburn wrote:
>>> -----Original Message-----
>>> From: DAve [mailto:[EMAIL PROTECTED]
>>> Trying to figure out dir-control gave me a
>>> headache and I never did get anyone to own up to knowing how it
>> worked.
>>> If someone would fix it, I would provide a 6 pack of Jones (any
>>> flavor),
>>> a carton of Marlborough reds, some tokens, a Magic Eight Ball, and a
>>> big
>>> bag of twizzlers to sweeten the deal.
>>> Dave
>> Oooh! That's a sweet deal...I'll throw in a 6 pack of Beer from Canada
>> from the brewery of your choice!
> Traction! Finally! I'll up the ante to guaranteed 24 hour turn around on
> testing any fixes, I'll setup a VMWare server just so I can test any
> patches.
> But that's not all... I will also throw in a pristine copy of a Mac
> rescue CD with all OSes from 7.1 to 8.6 including all patches, AND
> bottle of Jose Gold. Shipped of course, at no cost to the programmer who
> fixes dir-control.
I don't have any suggestions on exactly _how_ to fix dir-control at this
time, but I can try to explain how it works, since I did a lot of digging
into it to figure out how to do backfills for my patch.  This info is
based on the mysql dir_control table, but it should be (mostly) correct
for all backends.

The first entry in the domain column, dom_# is the placeholder for the
domain directory, and uses the vpopmail uid as the value of #.  All other
entries use the domain name for the real vpopmail domain (no aliases).

The second entry, cur_users, is the current number of entries in the
domain - this is important, because when this number is divisible cleanly
by 100, it increments the directory counter.  This is why I wrote my
patch, as the number doesn't accurately reflect the number of users in any
given directory, just the total for the domain.  Also, the 100 is a
compile-time value, although I have a separate patch that allows an extra
column in this table to change it on a per-domain basis.

The next 2 columns, level_cur and level_max, indicate how deep the tree 
is and how deep it can go.  0 means you're in the root directory, with no
hash dirs.  I think vpopmail supports going 3 levels deep
(<root>/<level1>/<level2>/<level3>), but I've only ever seen it go 2 (and
onle because of lots of deletions causing the above problem).  I'm not
sure why this is in the databse, but I guess it's there so you can change
it to 1 or 2 to prevent hashing or limit it to 1 deep - I haven't tried

After that, there are 3 each level_start and level_end columns.  This
indicates what characters in the hash list are available for use.  The
list consists of "[0-9][A-Z][a-z]" - I'm guessing these fields are there
so you can limit the hash characters to less than that, but again, I
haven't tried it.  Also, whil you can change the hash list, it's
hard-coded at compile time and I've never seen reason to mess with it -
see bigdir.c for details.

Next, there are 3 level_mod fields.  These are actually kinda pointless,
since they tell you the offset from the end of the root domain name where
the hash directory is located, but since the hash dirs are always single
characters (unless you set it all up manually - which I guess you could
do), these values are static and cannot change, so why they're in a
database I have no idea.  Level 0 is 0 because the hash dir is at
<root>/X, level 1 is 2 because it's <root>/X/Y, and level 2 is 4 because
it's <root>/X/Y/Z.

Next we have the level indexes, which is just the index in the hash list
for that level of hashing.  It starts at 0 for each level when the DB is
created, but really gets initialized to level_start when it's first used. 
When a deeper level maxes out at level_end, the higer level increments and
the maxxed out level goes back to level_start.  If the topmost level maxes
out, it creates a new level - no idea what it does if it maxes out at
level 3, as that would imply (although by no means guarantee, since
there's the dir increment issue mentioned above) 99 + (100*62) +
(100*(62^2)) + (100*(62^3)) users are already on the system (that's
potentially over 24M users, and even with deleting and re-adding users,
would require over 200K instances where the user count was exactly
divisible by 100).

Finally there's the_dir, which is the actual string of the current hash
directory - an empty string for no hash, "X" for level0, "X/Y" for level1,
and "X/Y/Z" for level2.  This is used for creating the new user directory
when adding users, and gets changed whenever the hash changes.

I hope this helps - I know just writing it has given me some ideas about
things that can be changed/simplified with it, but I have to get back to
me real job for the moment :)


Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics

Reply via email to