Is it supposed to be possible to deliver mail while mutt has the mbox open?
What is supposed to happen in the following scenario:- I'm viewing my incoming mail (inbox), looking at the index view in mutt. Some new mail arrives, delivered by procmail/python script/whatever to the inbox. Is there supposed to be some mechanism whereby mutt recognises that all that has happened is that new mail has been appended to the mbox? At present I *always* get the Mailbox was externally modified. Flags may be wrong. message. -- Chris Green
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
On 20.03.13 13:14, Chris Green wrote: What is supposed to happen in the following scenario:- I'm viewing my incoming mail (inbox), looking at the index view in mutt. Some new mail arrives, delivered by procmail/python script/whatever to the inbox. Is there supposed to be some mechanism whereby mutt recognises that all that has happened is that new mail has been appended to the mbox? The manual has a brief description, in section: 10. New Mail Detection (If mutt is well set up, that's on F1, but I figure you know that.) At present I *always* get the Mailbox was externally modified. Flags may be wrong. message. That happens here, if I have two mutts open concurrently. My guess is that your python isn't satisfying mutt's access/modification time requirements. Erik -- Mollison's Bureaucracy Hypothesis: If an idea can survive a bureaucratic review and be implemented it wasn't worth doing.
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
On Thu, Mar 21, 2013 at 01:05:27AM +1100, Erik Christiansen wrote: On 20.03.13 13:14, Chris Green wrote: What is supposed to happen in the following scenario:- I'm viewing my incoming mail (inbox), looking at the index view in mutt. Some new mail arrives, delivered by procmail/python script/whatever to the inbox. Is there supposed to be some mechanism whereby mutt recognises that all that has happened is that new mail has been appended to the mbox? The manual has a brief description, in section: 10. New Mail Detection (If mutt is well set up, that's on F1, but I figure you know that.) Yes, but it doesn't tell me what provokes the Mailbox was externally modified message. At present I *always* get the Mailbox was externally modified. Flags may be wrong. message. That happens here, if I have two mutts open concurrently. My guess is that your python isn't satisfying mutt's access/modification time requirements. It's satisfying them in that mutt recognises new mail arriving in all my (separate) mailboxes, that's working perfectly. It's just that if I happen to be *reading* the mbox where the new mail arrives I get the error message. I'm sure this didn't used to happen and I've not changed the delivery mechanism to my knowledge. What I want to know is:- Is it possible for a message to be delivered into an mbox that mutt is looking at without provoking the Mailbox was externally modified message? If the above is possible then what does the delivering MTA have to do so that the delivered message is 'N' and all others are left unchanged? -- Chris Green
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
What I want to know is:- Is it possible for a message to be delivered into an mbox that mutt is looking at without provoking the Mailbox was externally modified message? If the above is possible then what does the delivering MTA have to do so that the delivered message is 'N' and all others are left unchanged? I just took a look at the code (desperate measures!) and it gives me the answer. If the mbox in question has a message *appended* to it then mutt regards this as OK and will not output the error. It detects an append by looking to see if the 'message separator' before the appended message is exactly where the end-of-file was previously. I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. I need to play some more! :-) -- Chris Green
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
On 20.03.13 14:11, Chris Green wrote: What I want to know is:- Is it possible for a message to be delivered into an mbox that mutt is looking at without provoking the Mailbox was externally modified message? Yes. Here the message is New mail in this mailbox. (Confirmed by sending myself an email while in !) If the above is possible then what does the delivering MTA have to do so that the delivered message is 'N' and all others are left unchanged? I'd grab the source. The message is output by curs_main.c, on detecting (check == M_REOPENED). There are assignments to check in mx.c and curs_main.c, and mbox_check_mailbox() in mbox.c tells (in comments) that our guess at the meaning of M_REOPENED is correct. It's 2 a.m. here, so I'll leave it to you to figure out how to make the python behave so that it detects M_NEW_MAIL instead. (Is it respecting the file locking in mx_lock_file(0 in mx.c?) I see that function does a sleep(). I should do that too. Erik -- manual, n.: A unit of documentation. There are always three or more on a given item. One is on the shelf; someone has the others. The information you need is in the others. - Ray Simard
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
On Wed, Mar 20, 2013 at 02:58:58PM +, Chris Green wrote: What I want to know is:- Is it possible for a message to be delivered into an mbox that mutt is looking at without provoking the Mailbox was externally modified message? If the above is possible then what does the delivering MTA have to do so that the delivered message is 'N' and all others are left unchanged? I just took a look at the code (desperate measures!) and it gives me the answer. If the mbox in question has a message *appended* to it then mutt regards this as OK and will not output the error. It detects an append by looking to see if the 'message separator' before the appended message is exactly where the end-of-file was previously. I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. I need to play some more! :-) I have found my problem! My (python) MTA puts a blank line at the start of each message before the From MAILER-DAEMON Wed Mar 20 14:27:05 2013 line which is the mbox start line. As described above mutt sees the start as being at the From so it thinks the mbox has been modified otherwise than by a simple append. I guess something must have changed in the python libraries (or maybe in mutt) to have changed this logic because, as I said, it did used to work OK. I'll just have to fiddle something somewhere. I can probably remove the empty line in my python code. -- Chris Green
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
* On 20 Mar 2013, Chris Green wrote: I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. When your script delivers a message, does it append a message and then a blank line, or does it append a blank line and then a message? -- David Champion • d...@bikeshed.us
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
On Wed, Mar 20, 2013 at 10:11:06AM -0500, David Champion wrote: * On 20 Mar 2013, Chris Green wrote: I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. When your script delivers a message, does it append a message and then a blank line, or does it append a blank line and then a message? It appears to add a blank line and then the message. Has the mutt handling of this changed in the last few versions? The python way of doing this is correct according to the RFC as far as I can tell, there *should* be a blank line between the end of a message and the 'From ' starting the next message. Thus the python library I'm using does add this blank line. However mutt detects this as an error and outputs the messsage about the mailbox being modified. If, on the other hand, I append a message to my mbox file by hand and I *don't* put a blank line in then mutt is quite happy. Thus mutt is quite happy with the following in an mbox:- ... ... User-Agent: Mutt/1.5.21 (2010-09-15) Status: O Content-Length: 21 Lines: 2 Hello -- Chris Green From ch...@zbmc.eu Wed Mar 20 15:16:33 2013 Return-Path: ch...@zbmc.eu X-Original-To: ch...@chris.zbmc.eu Delivered-To: ch...@chris.zbmc.eu Received: by chris.zbmc.eu (Postfix, from userid 1000) id 88E8C381B20; Wed, 20 Mar 2013 15:16:33 + (GMT) Date: Wed, 20 Mar 2013 15:16:33 + From: Chris Green ch...@isbd.co.uk ... ... but strictly this is wrong as there should be an empty line there. -- Chris Green
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
* On 20 Mar 2013, Chris Green wrote: Has the mutt handling of this changed in the last few versions? Not that I know of, and I doubt it. The python way of doing this is correct according to the RFC as far as I can tell, there *should* be a blank line between the end of a message and the 'From ' starting the next message. Thus the python library I'm using does add this blank line. However mutt detects this as an error and outputs the messsage about the mailbox being modified. There absolutely should be a blank line. I think though that the order is wrong: mutt expects that a message (i.e. a From_ line) appears at the old EOF marker, and that the EOF marker is on/after a blank line. I think that if you adjust your filter to write the message and then a blank line instead of a blank line and then a message, the error will go away. -- David Champion • d...@bikeshed.us
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
Chris Green wrote: On Wed, Mar 20, 2013 at 10:11:06AM -0500, David Champion wrote: * On 20 Mar 2013, Chris Green wrote: I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. When your script delivers a message, does it append a message and then a blank line, or does it append a blank line and then a message? It appears to add a blank line and then the message. Has the mutt handling of this changed in the last few versions? The python way of doing this is correct according to the RFC as far as I can tell, there *should* be a blank line between the end of a message and the 'From ' starting the next message. Thus the python library I'm using does add this blank line. it is not correct. the blank line should be at the *end* of each message, not at the *start*. think about it. does an mbox file start with a blank line? no. it ends with a blank line. However mutt detects this as an error and outputs the messsage about the mailbox being modified. not an error, just a modification. presumably because there is an extra blank line, mutt sensibly concludes that the message that was previously the last message now has an extra blank line in it (i.e. the line that used to be a message separator but which is now a new last line of the message followed by the new message separator). If, on the other hand, I append a message to my mbox file by hand and I *don't* put a blank line in then mutt is quite happy. Thus mutt is quite happy with the following in an mbox:- because that is correct. the python code needs to be changed to write the From header, then the message, then the blank line. cheers, raf
