On December 9, 2002 at 13:47, "Birger Mortensen" wrote: > > An OUTDIR element is a chicken-n-egg problem. An archive's database is > > read first before any resource files are parsed, hence, your OUTDIR needs > > to be specified via the environment or the command-line. > > I don't get it - the arkive's database can be set by -dbfile on the command > line it must be a variabel for mhonarc at some point. > And i think that MhonArc works this way. > 1) Read command line > 2) Read dbfile > 3) Read resurcefile(s) > 4) Read/scan mailbox or stdin > 5) Work ! - Write html and dbfile
Kind of. Step (1) is a partial step to retrieve any parameters that are needed before any other processing. Examples, -quiet, -annotate, -stdout, ... After step (3), all the other command-line options are read since command-line options override anything else. > > But is it not possibel to move mhonarc.db out from the the outdir variabel - > after all there is no need for the webserver to store or read that file ? > Something like this > DBFILE default to ./mhonarc.db > search command line > search outdir from the command line > search current dir The next release will give you something somewhat related to what you are stating: the DBFILE will support an absolute pathname, allowing you to place an archive's DBFILE outside of the web-accessible area. (btw, you may want to see <http://www.mhonarc.org/MHonArc/doc/faq/security.html>) > I don't thint that will break any setup... > Then i would be possibel to do like this ( it is DOS syntaks but can be done > in all shells and perl etc ..) > > For %A in (*.db ) do mhonarc -add -dbfile %A > > And i get ALL MonArc lists updatet. Now I see what you are getting at. An initial issue is how to deal with LOCKFILE. Is LOCKFILE relative to where DBFILE is, or is it relative to where OUTDIR is? For example, take the case where someone decides to put all db files in one directory: /path/to/dbfiles/ .list1.db .list2.db .list2.db ... and does (use bash shell syntax), for i in .*.db; do; mhonarc -add -dbfile $i done This case would imply that LOCKFILE shold be relative to OUTDIR to avoid it bottlenecking processing of multiple archives in parallel. For example: for i in .*.db; do; mhonarc -add -dbfile $i & done The '&' puts each job in the background so all archives are updated in parallel instead of in a sequence. Your idea is interesting. > That was not the question - IF i use mhonarc -rmm 1-3 , the old messages > 1-3 don't popup at a new scan > Is the removed messageID not stored in some way by mhonarc ? It is not stored anywhere, but it would be nice if it did. A limitation is if you do an archive rebuild since the deleted id info will be lost, and if the undesired raw mail has not been removed also, they will reappear after a rebuild. A solution is to store in deleted message ids in a separate file and not use DBFILE. Hence, on a rebuild, the file can still be read to determine which messages should be skipped. --ewh --------------------------------------------------------------------- To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-USERS
