On Tue, Aug 28, 2012 at 08:42:09AM -0500, Derek Martin wrote:
> > Actually the MTA just appends to the file. It can get messy when a
> > second mutt or so with write access changes the mbox more
> > arbitrarily.
> 
> You can't assume that.  Well, YOU can -- it's probably true in most

Yes. It is just that the most simple LDA does just append new
mail to an mbox file. This can be arbitrarily complex.

> > > But, there's probably not really any good reason to read mail from a
> > > read-only NFS mount, so just stop doing that, and your problem should
> > > go away. 
> > 
> > The main reason is to see non-text without IO-redirection.
> 
> I don't really understand what you mean by this...  Seeing non-text

I am by default reading my mail not on the local machine, but via
ssh. Nevertheless I want to "see" some attachment on my local
workstation. NFS-export is more simple to setup than rdesktop,
vnc, or anything else.

> > Readonly because I liked to try with least possible privileges.
> 
> Well as you're seeing, read-only actually is not the least possible
> privileges.  For some operations you need to lock, and you can't do
> that without write access on the filesystem.  Or, there might be a
> hack to make it work, but if so it's not something that belongs in
> Mutt generally.

My point is that for readonly mailboxes mutt could work with
readonly (shared) locks, too. I do not see a point in trying a
write lock on a readonly file.  From my understanding of the
source, it re-reads the whole file anyway when it detects
non-trivial changes, which is as a net result pretty close to
leaving and restarting, but would be more comfortable.

I am still trying to understand what happens to the fcntl() lock
attempt, which is supposed to be first choice by Debian packages.
> 
> A read-only lock should succeed IIRC...  My guess is, after you do
> some operations to the mail box, mutt is trying to obtain a write lock
> so that it can update message flags, or what have you, and it can't.

Well, it does so even with an explicit -R option, which from my
understanding should not change the mailbox file in any way.

> I'd need to study the code to really be sure what's going on, but I
> don't think it's worth my time to do so...  I don't think this is
> going to work with Mutt today, and I don't think it's worth anyone's
> time to try to make it work in future Mutt.  

I was tempted enough to write a patch for it myself, if
necessary, after making sure that an nfs-specific locking issue,
so don't worry about your time, it is more that I now start
worrying about mine.

Bye,

Joerg

Attachment: signature.asc
Description: Digital signature

Reply via email to