What do people think about providing 

   roundup-admin 
lock/unlock

functions that would lock access to a tracker's 
files. So to
do a backup, its a simple matter of:

   % 
roundup-admin lock
   % cp -pr $TRACKER_HOME 
/tmp/tracker
   % roundup-admin unlock

rather then 
having to edit the aliases file to take the mail
gateways off line 
and stopping apache or the 
roundup-gateway to disable the 
web interface.

Richard said:

I like it. Please enter as 
a feature request on sf.net

Done.

-- rouilj

Logged In: YES 
user_id=707416

Could this be as simple as creating a file in the database area
called 
DB_LOCKED and having the db access routines return
errors if the 
file exists?

Logged In: YES 
user_id=707416

When the database is locked, the roundup-mailgw should
return an 
exit code of 75, (EX_TEMPFAIL IIRC) for sendmail,
or 111 for qmail 
MUA to indicate to sendmail or other MUA
that a bounce email 
should not be sen, and the email should
be queued and tried again 
later.

-- rouilj

Logged In: YES 
user_id=707416

When the database is locked, the roundup-mailgw should
return an 
exit code of 75, (EX_TEMPFAIL IIRC) for sendmail,
or 111 for qmail 
MUA to indicate to sendmail or other MUA
that a bounce email 
should not be sen, and the email should
be queued and tried again 
later.

-- rouilj

Logged In: YES 
user_id=38283

i second this.

Since we support database backends with transaction support for some
time now, running your database backup routine in a transaction is the
way to go. One example (but one I wouldn't necessarily recommend for
everyday backup) is the roundup-admin export command.