Apologies if this has been discussed before, but I have a little programming problem that I need solving. We use a client/server system to send encoded messages from a machine that allows our customer service people to add new users, change password, etc. on various servers controlled from a single server. We use Radius, so we want to update several Radius servers' passwd and pwd.db/spwd.db files, and keep them in sync. We also use Cyrus IMAP/POP3 server running sendmail 8.9. The problem I have, although there could be other manifestations that we haven't noticed, is with sendmail attemting to authenticate users. Not just the new/changed users, but any users that it happens to want to look up in certain very short time windows. My problem is this: When the server end of this password update system gets a request, it flock()s master.password, makes a temporary copy of /etc/master.passwd, /etc/passwd, /etc/pwd.db, and /etc/spwd.db, and uses ordinary write() to the update passwd and master.passwd copies and dbopen() etc to update these temporary copies of pwd.db and spwd.db. I copied this source from the standard pwd_mkdb FreeeBSD source, with minor modifications. So far so good. The password mechanism seems still to work fine while master.passwd is flock()'ed and the updates to the temporary files are going ahead. But once the update to the temporary files is done, of course my program has to update the real live files. It does this using rename(). I am pretty sure that it is during the tiny period of time that the rename() is happening that the problem occurs. Sendmail checks usernames on incoming mail, and, if it happens to be during this short period of time, it incorrectly thinks that the user doesn't exist. This is an extremely busy pop/imap server processing thousands of messages a day, and on a typical day I see maybe 10 messages fail in this way. Still, it's obviously important to us not to bounce mail that we should be delivering to we need to get this fixed. Anyone any ideas about maybe alternatives to rename() or some way that we could still have the password files fully available while we do this update? Philip Inglesant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message