Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>> If we had everyone who used m_draft use the same protocol, that might >> solve that problem. We'd need to make sure everyone who adds messages >> to a folder calls folder_addmsg(), though. It ends up being a huge >> pain to make sure we get it all right ... which is why it hasn't been done. >

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Paul, > the error it signals up-stack must tell its caller why it fails, so > that its caller can then try the next possible filename (message > number). only if it fails N times in a row (suggest 6 or 42, from the > prisoner and douglas adams) should comp then fail. That's a nice to have

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

On Wednesday, 4 January 2017 00:08:43 PST Ken Hornstein wrote: > ... > > If we had everyone who used m_draft use the same protocol, that might > solve that problem. We'd need to make sure everyone who adds messages > to a folder calls folder_addmsg(), though. It ends up being a huge > pain to

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>the error it signals up-stack must tell its caller why it fails, so >that its caller can then try the next possible filename (message >number). only if it fails N times in a row (suggest 6 or 42, from the >prisoner and douglas adams) should comp then fail. > >this should be done for all

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

On Tuesday, 3 January 2017 10:50:11 PST Ken Hornstein wrote: > >> - The file is created with creat(), which as you know does get called > >> with O_CREAT, but does not include O_EXCL. > ... > At least in the case of comp(1), by the time creat() is called it is > writing a new draft into that

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>Really, the safest thing to do for Laura's case is to use the MH environment >variable to point to a new .mh_profile that has it's own Path that doesn't >stomp all over your personal mail directory. Which, undoubtably, is why I have never run into this before. However, if the whole machine with

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>> - The file is created with creat(), which as you know does get called >> with O_CREAT, but does not include O_EXCL. > >Could that be considered a bug? That's comp(1). I UTSL this time and >repl(1) appears to fopen(..., "w") so it's no better off. Sigh. Maybe? Like I said, there are plenty

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Ken, > - The file is created with creat(), which as you know does get called > with O_CREAT, but does not include O_EXCL. Could that be considered a bug? That's comp(1). I UTSL this time and repl(1) appears to fopen(..., "w") so it's no better off. > Really, the safest thing to do for

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>I didn't look at the code. :-) I just thought that surely 42 is >open(2)'d with O_CREAT|O_EXCL so Unix annoints the race's winner. Geez Ralph, how long have you been working with MH/nmh?? And don't call me Shirley. The long answer is: - Programs will call m_draft() to get the name of the

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Ken, > > never both plump for 42. > > Are you sure about that? I am pretty sure from looking at the code > that can absolutely happen. I didn't look at the code. :-) I just thought that surely 42 is open(2)'d with O_CREAT|O_EXCL so Unix annoints the race's winner. -- Cheers, Ralph.

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>...but nmh commands wouldn't steal each other's draft? For example, two >comp(1)s racing each other are going to create 42 and 43, never both >plump for 42. Are you sure about that? I am pretty sure from looking at the code that can absolutely happen. --Ken

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, > I had forgotten all about the automated script (not only that it > existed, but that it was running on the machine where I don't usually > read my mail, but was using at the time). Does that mean your nmh mail directory is on some network-shared filesystem? -- Cheers, Ralph.

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Ken, > I suspect what happened is that your digest bursting program overwrite > your draft file between "repl" and "send", and your "send" sucessfully > sent the digest. I agree that seems to match the symptoms... > it's generally not safe to run two nmh programs simultaneously (we do > some

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Tue, 03 Jan 2017 04:42:19 +0700, Robert Elz writes: >Date:Mon, 02 Jan 2017 15:45:36 -0500 >From:Ken Hornstein >Message-ID: <20170102204537.c39325a...@pb-smtp1.pobox.com> > > > | Based on what you describe, I suspect what happened is

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Date:Mon, 02 Jan 2017 15:45:36 -0500 From:Ken Hornstein Message-ID: <20170102204537.c39325a...@pb-smtp1.pobox.com> | Based on what you describe, I suspect what happened is that your digest | bursting program overwrite your draft file between

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>But I am correct that nmh saved the file as something that I could have >overwritten later using a comp, reply or something like that? What I was >suggesting was that, at the point where send (I think) failed, it would >be good if nmh made a super-special copy of the draft which, due to its

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 14:59:02 -0500, Ken Hornstein writes: >>I checked. Yes, he did receive a digest at about minight my time. >>So, yeah, that was happening at that time. I still think that 'found >>an error trying to send something --> SAVE THAT DRAFT!!' would be a good >>thing to

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>I checked. Yes, he did receive a digest at about minight my time. >So, yeah, that was happening at that time. I still think that 'found >an error trying to send something --> SAVE THAT DRAFT!!' would be a good >thing to have. Perhaps we didn't explain it very well, but nmh _does_ that. But if

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 13:00:15 -0500, David Levine writes: >Laura wrote: > >> formatproc: /u/lac/bin/replyfilter >> >> could that be to blame? > >I doubt it. I don't think you would have reached the whatnow prompt >if it failed. As far as I can tell, all it does it set up the

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Laura wrote: > formatproc: /u/lac/bin/replyfilter > > could that be to blame? I doubt it. I don't think you would have reached the whatnow prompt if it failed. I also doubt that procmail would bother anything in your drafts directory, but you might want to verify by looking in your

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 17:32:49 +, Ralph Corderoy writes: >Hi Laura, > >Ken wrote: >> It would be interesting to make sure that in your drafts folder there >> exist a bunch of old messages with backup prefix. > >And that they linger, undisturbed. You could even deliberately create

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 12:23:04 -0500, Ken Hornstein writes: >>There was time for me to go to the kitchen, pour me a drink, come back >>and 'ohhh. What's this on my screen?', so plenty to time for something >>to munge things beneath me. Alas. I was hoping that a smarter send could

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, Ken wrote: > It would be interesting to make sure that in your drafts folder there > exist a bunch of old messages with backup prefix. And that they linger, undisturbed. You could even deliberately create one with a high number that's unlikely to be used in practice to see it remains,

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>There was time for me to go to the kitchen, pour me a drink, come back >and 'ohhh. What's this on my screen?', so plenty to time for something >to munge things beneath me. Alas. I was hoping that a smarter send could >understand that the hassle involved in removing an unwanted draft is minor,

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 16:27:54 +, Ralph Corderoy writes: >Hi Laura, > >> But my real query is about this 'apparently successful send'. Why >> wasn't it apparent that the send wasn't successful? Shouldn't a check >> of return codes have discovered the problem? > >What happens to

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, Another thought. You mention Emacs. Do you use the MH-E package or similar? Any other non-nhm MH programs? Could they be interfering with what we know of the normal flow? Is there any background job, perhaps relating to backups or disk cleaning, that would purge ,42? -- Cheers,

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, > Alas. I was hoping that a smarter send could understand that the > hassle involved in removing an unwanted draft is minor, and so > cautiuously bump the draft number for subsequent messages so that > there was no chance of reusing the draft number if it ever detected a > problem

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

I agree with what Ken said. Also, the annotation in the replied-to message only happens if the send was apparently successful. That happens first, then the draft is renamed to the backup. Both the annotation and the rename follow an explicit check for success. I can't explain how the send

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, > But my real query is about this 'apparently successful send'. Why > wasn't it apparent that the send wasn't successful? Shouldn't a check > of return codes have discovered the problem? What happens to successfully sent emails? Passed to a local MTA? A remote one? Does that leave

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 11:10:03 -0500, Ken Hornstein writes: >>But my real query is about this 'apparently successful send'. Why wasn't >>it apparent that the send wasn't successful? Shouldn't a check of return >>codes have discovered the problem? > >That is checked, and certainly if

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>But my real query is about this 'apparently successful send'. Why wasn't >it apparent that the send wasn't successful? Shouldn't a check of return >codes have discovered the problem? That is checked, and certainly if there is a problem I've always been returned to the whatnow prompt. And I

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>Definitely after I quit the editor. >I think _after_ the whatnow(1) prompt, as well, but it has long since >scrolled away. I don't remember the shell complaing about receiving an >unwanted 'send', so I think that whatnow received it. > >The mail did not go out to the person I was replying to,

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 10:11:06 -0500, Ken Hornstein writes: >>I was replying to somebody and got: >>*** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 *** >>/u/lac/bin/ra: line 2: 5931 Aborted/usr/bin/mh/repl -group -format > >I know we've had a number of

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 10:06:50 -0500, David Levine writes: >Laura wrote: > >> I think _after_ the whatnow(1) prompt, as well, but it has long since >> scrolled away. I don't remember the shell complaing about receiving an >> unwanted 'send', so I think that whatnow received it. > >So

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 14:56:33 +, Ralph Corderoy writes: >Hi Laura, > >> emacs. >> >> > What does `mhparam draft-folder' give? >> >> drafts (which seems to be working just fine -- drafts are indeed being >> created here) > >So emacs will have been editing drafts/42, say. > >> > Did

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

>I was replying to somebody and got: >*** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 *** >/u/lac/bin/ra: line 2: 5931 Aborted/usr/bin/mh/repl -group -format I know we've had a number of double-free errors and other memory-management related issues that we've stomped out

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Laura wrote: > I think _after_ the whatnow(1) prompt, as well, but it has long since > scrolled away. I don't remember the shell complaing about receiving an > unwanted 'send', so I think that whatnow received it. So it sounds like you did tell whatnow to send. Was the draft renamed to a

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, > emacs. > > > What does `mhparam draft-folder' give? > > drafts (which seems to be working just fine -- drafts are indeed being > created here) So emacs will have been editing drafts/42, say. > > Did repl die after you quit the editor and before the whatnow(1) > > prompt? > >

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

In a message of Mon, 02 Jan 2017 13:01:34 +, Ralph Corderoy writes: >Hi Laura, > >> /usr/bin/mh/repl -group -format >... >> I was replying to somebody and got: >> *** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 *** >> /u/lac/bin/ra: line 2: 5931 Aborted

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

Hi Laura, > /usr/bin/mh/repl -group -format ... > I was replying to somebody and got: > *** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 *** > /u/lac/bin/ra: line 2: 5931 Aborted/usr/bin/mh/repl -group -format I get similar looking malloc corruptions with nmh 1.6-3 on

[Nmh-workers] nmh should be more careful about when it unlinks draft files

In my bin I have a trivial shell script, called ra, reproduced here in its entirity. stty echo icanon crterase /usr/bin/mh/repl -group -format (I was having problems at a particular site with a program that kept dying on me and leaving me in an unpleasant mode, so I added the first line. It's