On Fri, Aug 24, 2012 at 08:06:58AM +0200, Joerg Dorchain wrote: > On Thu, Aug 23, 2012 at 01:49:07PM -0500, Derek Martin wrote: > > > > Not really. You can't really fix this. If mutt can't lock the folder > > then other processes (e.g. the MDA) can change the contents out from > > under Mutt while it's reading the file, potentially resulting in an > > inconsistent state. > > 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 cases -- but Mutt can't assume that it will always be true. Someone may have an MDA (not MTA, FWIW) that makes arbitrary changes to the mail spool based on some criteria. Mutt doesn't know what programs are accessing the mail spool, or how, or why. Another instance of Mutt is far from the only thing that could rewrite your mailbox out from under you. > > 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 involves writing a copy of the attachment/message part to a temp file and running a viewer on it... there's no I/O redirection AFAIK, and I'm not sure why it would matter if there were... In any event, I stand by what I said: there's probably no good reason to do this, and certainly mutt makes the assumption that it can write to the filesystem -- a very reasonable assumption, given what it does. > 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. > > - Dot-locking is (or at least was, and may still be) unreliable over NFS > > - POSIX locking (i.e. fctnl()) is not. > > I know. From reading the source, I am more puzzled what is really > happening. The mx_lock_file function tries fcntl first, and only if this > fails tries dotlocking. fcntl()-locking works at least once upon > startup. I'll do more debugging to get more insight into this. 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. 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. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpQwsPxfyvMw.pgp
Description: PGP signature
