Subject: Pine 3.95 deletes message on HUP

From: [email-masked] (Ken Marsh)
Date: 21 Apr 1997 14:34:21 -0400

Hi,

I'm having the problem where, when running MicroEmacs (not pico) under
Pine 3.95/Unix, if I get disconnected and later the session gets
killed, pine DELETES the message that was being composed.

Older version would leave it in /tmp as /tmp/pico.*. Now, Pine attempts
to save it, but just deletes it, which is NOT helpful at all. My one
most damning criteria for a BAD program is one that deliberately
destroys work. Right now, that describes 3.95.

I think this is a particularly nasty bug, but a bug report 2 months
ago has brought NO response.

Is this fixed in 3.96? Is there a work-around (short of makeing a copy
of each message as I'm composing it)? Using PICO is NOT an option,
as it doesn't do multiple buffer editing or macros.

Please e-mail.

Ken.
-- 
-------------------------------------------------------------------------
Mail: [email-masked]             | Edit a binary .INI file, then tell
WWW:  http://www.charm.net/~kmarsh | me that UNIX is too complicated.
-------------------------------------------------------------------------

---

From: Mike Brudenell <[email-masked]>
Date: Fri, 25 Apr 1997 09:35:04 +0100 (BST)

> destroys work. Right now, that describes 3.95.

Strange... I assume that most programs will lose your unsaved work if they
are interrupted or aborted.  This is the default action with an untold
number of programs; there is nothing "deliberate" about it.

In view the exceptions are those programs which deliberately make an
attempt to preserve your data, and that this is a sign of a GOOD program.

However it would perhaps be sensible if Pine, when attempting to rescue
your message with its last dying gasp, left the temporary file in place if
it couldn't rescue its content.  Have you looked at the source code to see
exactly what it does in this situation?

> as it doesn't do multiple buffer editing or macros.

Incidentally, I'm assuming you do actually _have_ something in this
temporary file?  You may not have if you've just been typing in a message
from scratch...

The reason I ask is that Pico (the standalone editor, and also in disguise
as Pine's built-in editor) is the thing which actually attempts to save
your in-memory editing buffer to disk as it dies.  Only if it does this
can Pine then rescue the data from the file and store it as an interrupted
message.

However I believe that MicroEMACS (which we also use here, but as a
standalone editor) does _not_ do this last-gasp save-to-disk of your
editing buffer.  This means that if interrupted it simply loses all the
changes you have made since the file was last saved to disk.

Thus if you are starting a message from scratch, typing it into
MicroEMACS, and are interrupted MicroEMACS will _not_ save your message to
disk.  Instead all that is left there is an empty file.  Pine presumably
tries to rescue the contents of the file but finds it empty; there's not a
lot it can do in that situation!

So if my suppositions and assumptions are right you should be pointing the
finger at MicroEMACS for not last-gasp-saving your file rather than at
Pine for not rescuing it.

If this seems to be the case you might like to look at ASAVE (auto-save) 
mode within MicroEMACS.  This saves your file to disk every N characters
typed (N defaults to 256, but can be changed by altering the $asave
MicroEMACS environment variable):

You may like to try using one of these commands within Pine's
Configuration Screen to invoke MicroEMACS to turn on ASAVE mode (and also
WRAP -- word-wrap -- mode if you wish):

	ue -i\$gmode NNN
or	ue -i\$gmode NNN -i\$asave KKK

where:

* ue should be replaced with whatever command you use to start
  MicroEMACS;

* NNN is either 1 (for WRAP mode only), 128 (for ASAVE mode only) or 129
  (for both WRAP and ASAVE modes);

* KKK is the number of keystrokes after which to automatically save your
  file to disk (only needed if you want to change the value from the
  default of 256).

Note that you may have to experiment with extra levels of "\" quote
characters to get the above commands through the shell Pine uses to invoke
the command.  Perhaps something like this might be needed:

	ue -i\\\$gmode NNN

Also note that once ASAVE mode automatically saves your editing buffer to
disk it will replace the current content of that file: there's no going
back if you change your mind and cancel out of MicroEMACS ... the file
will contain the information stored at the last automatic save.

Cheers,

-- 
Mike Brudenell                                         <[email-masked]>
------------------------------------------------------------------------
The Computing Service, University of York, Heslington, York, YO1 5DD, UK
Tel: +44-1904-433811  FAX: +44-1904-433740  http://www.york.ac.uk/~pmb1/

* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *

---

From: Ken Marsh <[email-masked]>
Date: Fri, 25 Apr 1997 10:06:49 -0400 (EDT)

> number of programs; there is nothing "deliberate" about it.

You misunderstand. Pine 3.95 actually DELETES the /tmp/pico.* file
that HAS BEEN saved by MicroEmacs, when receiving a HUP. It also
fails to transfer it to it's dead letter save file. On next
startup it suggests continuing when invoking compose, then says that 
there is nothing to continue.

This, going out of its way to delete a saved file, is EVIL.

Ken.

---

From: Mike Brudenell <[email-masked]>
Date: Fri, 25 Apr 1997 15:33:30 +0100 (BST)

> This, going out of its way to delete a saved file, is EVIL.

Hmmm.... using the tests I have done on our Unix systems with its version
of MicroEMACS I still stand by what I said later on in my article.

Are you _sure_ MicroEMACS is saving your work to the temporary file?  It
doesn't on ours... I've just tried using MicroEMACS (standalone, not
confusing things by using it from within Pine) to edit an empty file.  I
then sent it a HUP signal and it did _not_ save my changes to the original
file on disk.

If this is also happening on your system then it is no wonder that Pine
can only rescue an empty file.

Have a try of the following just to convince me and others:

	Login session #1			Login session #2
	----------------			----------------
	touch testfile
	ue testfile
		<type in something>
						kill -HUP pid
						  where pid is the pid of
						  the other session's
						  MicroEMACS process
	cat testfile

Is the result still empty, or has the "something" you typed in been saved
there?

Cheers,

---

From: Ken Marsh <[email-masked]>
Date: Fri, 25 Apr 1997 11:24:55 -0400 (EDT)

Hi,

Please read the following carefully.

On Fri, 25 Apr 1997, Mike Brudenell wrote:
> Are you _sure_ MicroEMACS is saving your work to the temporary file?

When I hit ^X^S, I GUARANTEE you that MicroEmacs saves it's file
to /tmp/pico.$$. Then, HUPPing it's parent process, PINE 3.95,
causes both to die, but not before PINE DELETES the existing,
populated, edited file in /tmp.

  It
> then sent it a HUP signal and it did _not_ save my changes to the original

You continue to misunderstand. I AM SAVING THE FILE. I type ^X^S every
few keystrokes under MicroEmacs. I am not relying on some auto-save
feature (that doesn't exist on my MicroEmacs 3.12 as far as I know.

PINE 3.95 is evil because it deletes the file when HUPPed, and fails
to copy it first.

Ken