Michael Ströder writes: What kind of breakage are you afraid of slipping through? You'll know if it's outside any of your suffixes, or if it spans two databases. Though the latter only after the first has been modified. -- Hallvard

Opening the correct db based on entries present in the file seems fairly reasonable. I'd even consider re-opening different db's as necessary through the file if they include multiple suffixes, though that's more work. As far as error messages, this removes the number of cases where someone would see a message, so it should help on the bad questions front. While delivering simple messages is good, it's rather silly to present errors when we can clearly identify what the user wants, the semantics are unambiguous, and there is a straightforward path to implementation. Matthew Backes Symas Corporation mbackes(a)symas.com

There isn't much hazard involved here; typically slapadd will be done to empty databases. If they have multiple suffixes they likely have multiple ldif files. Automatically loading into "the other backend" several times would still produce the desired end result, as they are more or less independent. If they have one single ldif for multiple suffixes, then traditional slapadd can offer them no help at all. In the case where they have multiple backends and some are populated and some aren't, and they pick the wrong ldif file, likely either it is a backend they needed to load soon anyway or the objects are already present and nothing will happen as a result. Better messages are always a good idea. It may be a good idea to emit informational warnings about backend selection. Purely from a UI perspective, -b "" sounds like loading LDIF into the rootDSE; a bit confusing perhaps. Additionally, empty arguments tend to cause great confusion between users and their shell. -n detect sounds okay. It might be a reasonable default as it is only changing behavior for what was previously an error condition. While users might rely on all sorts of odd features, it seems unlikely that anyone relies on slapadd to print and error and do nothing in this case. Perhaps if someone were used to populating suffixes with ldifs, and used slapadd in a for-loop to do this, checking the exit code to find out when the right ldif had been found. Seems far-fetched though. Still, having it available as an option is better than nothing. Matthew Backes Symas Corporation mbackes(a)symas.com

Pierangelo Masarati writes: I don't quite get it. Which unintended database? There is only one database into which any entry will go, based on the DN. If you just mean the user slapadds an LDIF he shouldn't have slapadded, well, though. The user might do lots of things he didn't intend to, like accidentally typing rm * instead of rm something*. Besides, the slapadd can succeed already since there already is a default database to try. That's always good. If so, I'd prefer -b- and -n-. -- Hallvard

Pierangelo Masarati writes: Right, but this doesn't mean -b/-n affects which database an entry will be put in. It merely affects whether the attempt to add the entry will succeed. Which is why I've been a confused by the previous messages. s/noclobber/-i/. (noclobber prevents redirects from overwriting.) And we are talking about the case of not using either option. I agree, which is why I suggested to remove it:-) But removing the default without adding auto-choice would be an option too. The default wasn't much of a problem before, but with the addition of cn=config people will need to play with multiple databases. Anyway, let's see for now if your improved error helps helps. -- Hallvard

Hallvard B Furuseth wrote: That's just a first trivial round, I0m open to suggestions (like Michael's). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------