If everything is successful, it could cycle through the list and rename
to their "true" names. If an error is encountered, the files would be
removed.
I am not sure how much this will help.
My thinking is that it might prevent corruption for real-time archives.
I do real-time archiving myself, and sometimes the web pages get totally
messed up and I have to go in and rebuild them. It would be better if
the list just appeared slow, but there were no dead links, etc.
In case of failure, the message would be stored in an
errorfile and the system administrator notified.
This is not easy to do, refering to the last sentence. MHonArc does
not buffer the original message data (one of the reasons I advocate
to store off the original messages).
Yes, I agree entirely. I didn't mean to imply that it should be
MHonArc's task -- just that it should be done. I do everything through
procmail and perl scripts so that I can be notified in case things
didn't go as planned.
One problem I see with your method is that it would be impractical if
messages are archived as they arrive. If there is decent volume, the
extra overhead can be too costly. Should be okay if done via cron and
disk space is not an issue.
Yes, it could be a real problem on some of the lists that I've got (over
100 messages / day). I'm trying some tests to see if doing an rdist
to localhost would work, or possibly keeping a dbm database of
timestamps/filenames. Any changed entries would be copied instead of
the entire directory. Don't know if this will make it slower or faster.
Definitely more secure than rdist though. :)
Chris
