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
signature.asc
Description: Digital signature
