I use 'UMASK=002' at the top of my procmail script (without the quotes).
This isn't part of mhonarc...just an env variable that procmail picks up
if you define it. Works just fine.
benjamin grosser, digital visualization facility 217.244.5669 (ofc)
beckman institute for advanced science and technology 217.244.8371 (fax)
405 north mathews avenue, urbana, illinois 61801
On Tue, 26 Nov 1996, Earl Hood wrote:
1. When I run mhonarc from the command line the files are created
mode 0644 (which is what I want). When mhonarc is run via procmail, the
files are created mode 0600. Changing the umask using the mhonarc command
line option does not seem to have the desired effect. Files end up mode
0002 and various other nonsense permissions. Can someone steer me in the
right direction to resolve this problem? Changes to procmail?
Not familiar with procmail, others will have to help here. A thing
to note is you procmail script will be running under the uid that
sendmail invokes procmail. I believe there is an option in procmail
to set the umask.
2. Using the -idxsize, -maxsize, and -multipg options in 2.0 result
in the index files being trashed once the archive exceeds maxsize.
Running -editidx fixes this. Should all my adds be run with -editidx
option set? What does this do to performance?
I think the problem is that the code for detecting which messages need
to be updated when messages are deleted from maxsize has not been
updated for v2.0. The new thread stuff adds additional complexity
to the problem and the code has not been updated to take this in
account. I.e. I'd guess the behavior you are seeing is that some
thread next/prev links are not correct since mhonarc is not updating
some messages because it improperly believes some messages do not
need updating. The -editidx option forces all message to be reditted.
Hence, everything is okay after -editidx.
The performance hit of -editidx will depend on the size of your
archive and how fast your machine is. -editidx cause all message
files to be edited and all index pages to be rewritten. This is alot
of file I/O, so the performance can be a problem if you are updating
the archive as messages come in.
Hopefully II'll get some time to fix the bug in the near future.
Earl Hood | University of California: Irvine
ehood(_at_)medusa(_dot_)acs(_dot_)uci(_dot_)edu | Electronic
http://www.oac.uci.edu/indiv/ehood/ | Dabbler of SGML/WWW/Perl/Stuff