On 2007-09-25, at 1348, Tom Collins wrote:

I'm all for keeping it, but someone should fix it. On my server, with a cdb backend, I have the following structure:

main directory: 65 domains
0: 25 domains
1: 2 domains
2: 2 domains
3: 0 domains
4: 3 domains
5: 44 domains

to me this looks like a bunch of domains were deleted at some point... either that, or different versions of vpopmail have had or not had the "store domains in numbered directories" option at different times.

I'd love to see vadddomain do a better job of back-filling domains. Maybe vadddomain and vdeldomain could work together to keep directories at a balanced level.

i'm not sure that vdeldomain has, or should have, anything to do with it.

Keep track of the next directory to fill in a file (which needs to be protected by a file lock). The .dir-control file is supposed to work that way.

On vdeldomain, if the domain came out of a directory "less than" the next_directory, update next_directory.

On vadddomain, if next_directory has 100 domains after the addition, scan forward until you find a directory with <100 domains and update next_directory.

i think trying to track it in a file is overkill... unless you're adding several domains per minute, or you have multiple people adding domains, you should just be able to add the bucket-selection code to vadddomain().

It should be possible to make the code generalized enough to work for the domains directory and the individual domain directories (for managing users via vuseradd and vuserdel).

not too difficult... i'll throw something up on the dev list in a few minutes. i would have figured that logic was built into vadddomain() and vadduser() already though?

again... on the dev list.

----------------------------------------------------------------
| John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
| http://www.jms1.net/                         <[EMAIL PROTECTED]> |
----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-1656880303867390173 |
----------------------------------------------------------------


Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to