On Mon, Dec 15, 2003 at 06:52:25PM +0100, Ulf von Barth wrote: > I have been using your program mutt to read my mail at home > while on-the-road. In the past I had problems saving my read > mail to a disc on another machine where I have my home directory. > The mail arrives at a machine which is running Red Hat Linux 7.2 > (it has an intel processor Pentium III) and I want to save it to > a similar machine. Using an mbox over NFS is dangerous. Either switch to maildir format, or switch to IMAP. > In those days, saving a mail through mutt > resulted in the following message: > > Couldn't lock /nfs/urd/users/barth/folders/filename . > > within mutt! That's because lockfiles over NFS aren't reliable without lock-step synchronization (which is an efficiency nightmare). > I contacted mutt-org but there was no suggestion but to recompile > mutt with other options. That's a bogus suggestion, AFAICT. No option would allow Mutt to lock over NFS, since the problem is inherent to NFS by design. > For a long time the problem went away by itself but has now > reappeared. I am not going to recompile mutt because I am not the > system administrator. That's fine. You could compile your own version of Mutt if you wanted, but as I said it won't solve your problem anyway, so why bother? > I am sure the problem has to do with the > system on the machine with the mail (the mailserver). The problem has to do with mbox over NFS being bad. > In the messages log I find: > > Dec 2 16:41:07 oden kernel: lockd: cannot monitor 130.235.92.60 > Dec 2 16:41:07 oden kernel: lockd: failed to monitor 130.235.92.60 > > where you see the IP number of the machine where I have my home > directory (oden is the mail server). > I now have the following questions for the mutt org.: > 1. How does mutt lock files on other machines? beats me ;-) > 2. Can one (without recompiling) stop mutt from trying to lock the > files on the other machine? not as far as I know ... if you recompile, you may be able to persuade it to use mutt_dotlock, and then replace mutt_dotlock with a symlink to /bin/true, but as I'll point out below, you may not want to do that. . . > 3. In your documentation it says that there is a variable > dotlock_program which, as default, points to the standard > location /usr/local/bin/mutt_dotlock which is supposed to be > the standard location of the binary of the program which does > the file locking in mutt. > There is no program in that position on my machine! > Which program does mutt use? Obviously, Mutt's not configured to use its own mutt_dotlock. You'll need to recompile if you want to use it. > 4. I would like mutt not to lock any files. That's rather dangerous. Imagine for a second what happens when you're in the middle of deleting a message, so Mutt's in the middle of writing to the mbox, but suddenly new mail arrives, and mail.local (or procmail, or whatever your local MDA is) starts writing it to your half-changed mbox. As you can tell, the net result may be (a) your new mail getting overwritten by Mutt's changes; (b) Mutt's changes being overwritten by your new mail; or (c) some combination of the above, most likely resulting in a corrupted mbox. > I tried to make > /usr/local/bin/mutt_dotlock point to /bin/true - but this > had no effect. Why? If Mutt's not configured to use its own mutt_dotlock, it doesn't matter what mutt_dotlock contains - it won't be touched. > Finally a question of a different kind. > I often - these days - receive mails wich Attachments in html code. > How and where do I specify that mutt should use netscape to open > such Attached mails? man 5 mailcap If you're too lazy to read, here's an example: $ grep text/html ~/.mailcap | grep "3m -T" | sed 's/w3m -T text\/html/netscape/' text/html; netscape %s ; needsterminal ; ; - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpwm1iXHzMUe.pgp
Description: PGP signature