<<< Date Index >>>     <<< Thread Index >>>

Re: locking files over NFS



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