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 majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-USERS
