> Tren Blackburn wrote: >>> -----Original Message----- >>> From: DAve [mailto:[EMAIL PROTECTED] <snip> >>> 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 it. 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 :) Josh 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 [EMAIL PROTECTED]
