Subject: Pine and read-only folders

From: James Kirkpatrick <[email-masked]>
Date: Thu, 09 Sep 1999 15:24:06 -0600 (MDT)

I've noticed an unfortunate change in Pine 4.10 versus 3.96.  In the older
Pine, if I started Pine from two different sessions the second one would
detect the first one, and attempt to "hijack" the folders and force the
older session to read-only.  In 4.10 the behavior is reversed in a sense:
the newer Pine detects the older one and leaves itself in read-only mode.

I consider this unfortunate because of a common problem:  A student logs
in and is using Pine to read mail.  He then loses the session (power
failure, reboot, whatever) but the UNIX server doesn't know anything has
happened.  He then logs in again and now has read-only access (unless he
knows enough to find and kill his other process).  Thus, the new behavior
is less desirable than the old behavior.

Is this intentional, and/or can it be made to behave in the older manner
via a config variable?

Jim Kirkpatrick
[email-masked] (the "other" UW :-)

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Mike Miller <[email-masked]>
Date: Thu, 9 Sep 1999 18:54:18 -0500 (CDT)

> the newer Pine detects the older one and leaves itself in read-only mode.

I agree 100%.  Changing it was a bad choice, wasn't it?  I don't
understand the reasoning.

> [email-masked] (the "other" UW :-)

I went to University of Wisconsin, yet another UW!

Mike

-- 
Michael B. Miller
University of Missouri--Columbia
http://taxa.psyc.missouri.edu/~mbmiller/

---

From: Dave Horsfall <[email-masked]>
Date: Fri, 10 Sep 1999 10:09:56 +1000 (EST)

> the newer Pine detects the older one and leaves itself in read-only mode.

Yes, I prefer this behaviour, in fact.  Occasionally I forget I have
a session running, and start up another one.

> is less desirable than the old behavior.

They'll soon learn to find and kill the other process...

> Is this intentional, and/or can it be made to behave in the older manner

A config switch would be nice: [ ] hijack-old-session :-)

-- 
Dave Horsfall VK2KFU  [email-masked]  Ph: +61 2 9978-7493 Fx: +61 2 9978-7422
Geac Computers P/L (FGH Division) 2/57 Christie St, St Leonards 2065, Australia

---

From: Timothy J Luoma <[email-masked]>
Date: Thu, 9 Sep 1999 23:07:43 -0400

Replying to message of Fri, 10 Sep 1999 10:09:56 +1000 (EST)
	from Dave Horsfall <[email-masked]>
	regarding ``Re: Pine and read-only folders''
	
> a session running, and start up another one.

As do I... but I also have the other experience of a dropped connection.

> They'll soon learn to find and kill the other process...

You assume that they __can__ login as kill other processes.

I had an account very recently which was made 'pine only'

> A config switch would be nice: [ ] hijack-old-session :-)

That does seem to be the best "option" here (pun intended)

TjL

---

From: Andy Malato <[email-masked]>
Date: Thu, 09 Sep 1999 23:45:54 -0500

> > a session running, and start up another one.

yeah that happens often.

> I had an account very recently which was made 'pine only'

'pine only' -- what in the world were they thinking?

Someone should write a script, that detects for idle time, when pine is running
as 
a process, and finds that you have been idle for 5 minutes, that PS-ID should
be killed, therefore making the possibility of starting a second session of pine
less likely, I'll take a look into a script and see what I can do.

	---Andy

---

From: Osman%Pine <[email-masked]>
Date: Fri, 10 Sep 1999 07:32:50 +0200 (CEST)

> less likely, I'll take a look into a script and see what I can do.

Why should you?
That way someone isn't permited to stare at his mail.
Said diferently someone must be able to read his mail in his own tempo,
some mails are long or difficult to understand quickly...

BTW: I think droped connection detection is something for the OS/shell and
not to a userland application.

TTYL.
-- 
            Give a man a fish and you feed him for a day;
     teach him to use the Net and he won't bother you for weeks.

---

From: Lea <[email-masked]>
Date: Fri, 10 Sep 1999 09:07:37 -0600 (MDT)

Something else we found after installing 4.10 was that the first-unseen
selection in the Incoming-startup-rule causes Pine to open at the first
message in the user's inbox rather than at the first unread message.
Changing the default selection from first-unseen to first-recent works
better - it opens the inbox at the first message marked new that has
arrived since the last time you opened Pine - but why doesn't first-unseen
work?  I ran this past the sysadmin here who installed the software.  He
says it's a bug.  Is it?  Or is there something he could tweak that would
fix first-unseen's behavior?

Lea

---

From: "Adam H. Kerman" <[email-masked]>
Date: Fri, 10 Sep 1999 15:32:25 -0500 (CDT)

>From: James Kirkpatrick <[email-masked]>
>Date: Thu, 09 Sep 1999 15:24:06 -0600 (MDT)

>the newer Pine detects the older one and leaves itself in read-only mode.

There's no difference in how the newer session is handled between the two
versions. In 3.96, a new session that opened a folder already in use would also
display that folder as read only.

>is less desirable than the old behavior.

Hardly. The user must be taught to kill zombie processes if need be.

Sometimes I can lose carrier while telnetting during a ppp session. If I
haven't sent any additional keystrokes, it's possible to suspend the telnet
session and restore the connection and then resume the telnet session as if
nothing had happened.

---

From: "Eduardo Chappa L." <[email-masked]>
Date: Fri, 10 Sep 1999 13:48:43 -0700 (PDT)

*** Lea ([email-masked]) wrote Today:

:) 
:) Something else we found after installing 4.10 was that the first-unseen
:) selection in the Incoming-startup-rule causes Pine to open at the first
:) message in the user's inbox rather than at the first unread message.
:) Changing the default selection from first-unseen to first-recent works
:) better - it opens the inbox at the first message marked new that has
:) arrived since the last time you opened Pine - but why doesn't first-unseen
:) work?  I ran this past the sysadmin here who installed the software.  He
:) says it's a bug.  Is it?  Or is there something he could tweak that would
:) fix first-unseen's behavior?

It's not a bug, but a feature. The point is that there are two kind of new
messages. Imagine that you have your INBOX empty and then exit pine,
assume further that when you read your e-mail next time you have two new
messages. Checking "first-unseen" or "first-recent" will have the same
effect. Assume that you read the first message but *DO NOT OPEN* the
second one and quit pine. Next assume that a third message arrives to your
INBOX, then the next pine that you use pine the message that you did not
read will be called "UNSEEN" and the one we called third will be called
"NEW". If you have set "first-unseen" set then you will open INBOX in the
UNSEEN message, but if you have it in "first-recent" it will open it in
the real "NEW" message. It depends on how you display your index if you
are able to distinguish this by reading it. The default in pine is that
"UNSEEN" messages and "NEW" messages are both displayed with a "N" in the
index, but you can change this so that "UNSEEN" messages have a "U" in
front of them and "NEW" messages have a "N" in front of them. If you want
to do this you will have to go to your configuration, check "index-format"
and use "IMAPSTATUS" instead of "STATUS", which is the default.

I hope this clarifies the point you made. Maybe the help in pine should
include a pointer to "index-format" and/or "IMAPSTATUS" from the
incoming-startup-rule help.

Eduardo
http://www.math.washington.edu/~chappa/personal.html

---

From: Mike Miller <[email-masked]>
Date: Sun, 12 Sep 1999 23:11:05 -0500 (CDT)

What did Pine 3.96 do when the first open session was in the process of
editing a message?  If the first session was subsequently killed, the
incomplete message should have been saved, but would it be saved if the
session was 'read-only'?  What if the user returned to the first session
somehow and finished composing the message and mailed it out--would the
Fcc be saved properly?  (If the session is read-only, can it write the
Fcc?)

If any of these scenarios caused problems in 3.96, it might explain why
the pine team made the change in 4.10.  If they don't cause problems, I
don't understand the need for the change.

Regards,

Mike

---

From: Timothy J Luoma <[email-masked]>
Date: Sun, 12 Sep 1999 23:56:29 -0400

Replying to message of Fri, 10 Sep 1999 15:32:25 -0500 (CDT)
	from "Adam H. Kerman" <[email-masked]>
	regarding ``Re: Pine and read-only folders''
	
> There's no difference in how the newer session is handled between
> the two versions. In 3.96, a new session that opened a folder
> already in use would also display that folder as read only.

Not so, at least not here.

I opened a mailbox with 3.96.
I then started a second session with 3.96
I saw this in the original session:

	[Another Pine is accessing folder.  Session now Read-Only.]

And I see this in the 2nd PINE session

	[Trying to get mailbox lock from process 1630]
and then
          [Folder "test" opened with 2 messages]

I did the same thing with pine 4.10 and immediately get this message

	[Mailbox is open by another process, access is readonly]
and then
	[Folder "test" opened with 2 messages READONLY]

> Hardly. The user must be taught to kill zombie processes if need be.

__IF___ that option is even available to them (there are menu-driven shell  
accounts which give access to PINE but not to commandline)

Even if it is, I'm not sure why this behavior was changed, and why it is  
"better" when it is easy to see when it could become a problem.

TjL

---

From: "Daniel Sands" <[email-masked]>
Date: Mon, 13 Sep 1999 13:59:47 -0600

> "better" when it is easy to see when it could become a problem.

Why doesn't Pine detect when the TTY is dead and kill itself?  Since it's
supposed to be an interactive mailer, it makes no sense to keep going when no
more input can be given.

---

From: Bob Rasmussen <[email-masked]>
Date: Mon, 13 Sep 1999 13:11:47 -0700 (PDT)

I believe someone on this thread suggested that when a process was orphaned,
it was possible to reattach to it. Is that true? I've never been able to
figure out a way to do that. Please explain.

Simple case: I'm using a modem to access Unix. The modem line drops, and the
Unix is configured to not quit on a SIGHUP. I dial back in. a 'ps' shows the
process still running. How can I reattach to it?

-- 
Regards,
....Bob Rasmussen,   President,   Rasmussen Software, Inc.

personal e-mail: [email-masked]
 company e-mail: [email-masked] or [email-masked] or [email-masked]
 ftp://ftp.anzio.com               voice: 503-624-0360
http://www.anzio.com                 fax: 503-624-0760

---

From: James Kirkpatrick <[email-masked]>
Date: Tue, 14 Sep 1999 09:41:27 -0600 (MDT)

This is rather easy to do on VMS, one of the supported operating systems
for Pine.  On UNIX (Solaris) I'd like to know ...

Jim

---

From: James Kirkpatrick <[email-masked]>
Date: Tue, 14 Sep 1999 09:40:18 -0600 (MDT)

Define "dead".  If a PC powers off, the host can't tell if it's dead or if
the user simply hasn't typed something for a while.  Then, define "a
while".  Some systems kill idle processes, but only after several hours or
days (or not at all); the user might want to get at their mail NOW, not in
a few hours.

Jim

---

From: Mike Miller <[email-masked]>
Date: Tue, 14 Sep 1999 11:27:51 -0500 (CDT)

I'm using Solaris.  I think that it is not possible to run a process in
foreground if it was started by another shell.  Maybe I'm wrong, but I've
never seen it done and I've tried to find a way and I've failed.

There is a program called 'screen' that might allow you to reconnect to a
process from a new shell, but screen has to have been called in advance, I
think.  I don't know much about screen, but in Solaris OS you can get info
as follows:

man screen

Regards,

Mike

---

From: Jessica Rasku <[email-masked]>
Date: Tue, 14 Sep 1999 12:14:45 -0700 (PDT)

> for Pine.  On UNIX (Solaris) I'd like to know ...

	Ah, maybe that's where I got this idea from.  My experience with
VMS.  Thanks.  Maybe it's not possible, but it should be somehow...

							Jessica

-- 
Jessica Rasku, Box 270, Rossland, B.C., V0G 1Y0, (250) 362-5701, 
LinuxBox: (250) 362-9668.

List manager: [email-masked] 
     send command help ---- To get help with majordomo
               or lists ---- To get a list of all lists on server.

WWW: <http://www.geocities.com/RainForest/Andes/8749>

---

From: Osman%Pine <[email-masked]>
Date: Wed, 15 Sep 1999 04:15:11 +0200 (CEST)

On Tue, 14 Sep 1999, James Kirkpatrick wrote:

> the user simply hasn't typed something for a while.

Well if keep-alive is been used and the line drops:
- The modem will hangup if a modem is used.
- The process attached to the connection would get a SIGHUP,
  and quit. (eg: pppd if that's used.)
- The shell should get a SIGHUP and quit.
- All its child's that still are attached to the parent (the shell),
  should get a SIGHUP / SIGQUIT / SIGTERM / SIGABRT or whatever,
  and they should quit.

> Then, define "a while".

"A while":
Longer than a moment and shorter than forever. ;-)

> Some systems kill idle processes, but only after several hours or
> days (or not at all);

That's correct behaviour me thinks...

> the user might want to get at their mail NOW, not in a few hours.

[BOFH mode on]
Well you know: those users want all kinds of things...
[BOFH mode off]

;-))
TTYL.
-- 
                Where do you think you're going today?

---

From: "Daniel Sands" <[email-masked]>
Date: Wed, 15 Sep 1999 14:15:34 -0600

I define "dead" as when the user's telnet connection is dropped, thus ending
the login session and freeing the PTY.  It is of interest, though, that Pine
on my IP's machine will be killed by a dropped connection.  This may be due to
my shell program sending it a HUP signal, though.

---

From: James Kirkpatrick <[email-masked]>
Date: Wed, 15 Sep 1999 14:39:02 -0600 (MDT)

There are still different flavors of "dead".  If you are dialed in and
drop, the modem sends a signal to that effect to whatever it's connected
to, and in many cases that propogates back to the server which then kills
the necessary processes (e.g. sends a SIGHUP to the shell).

However, if the client is a PC with an ethernet card, plugged in to the
campus network, and telnetted to the server, then things like a power
failure on the client end (or control-alt-del, or poke the reset button,
or ...) are not noticed on the server.  The connection is not dropped
because nobody knows what's happened.  Telnet does not include a
"heartbeat" to tell one end or the other that anything's wrong.  And it's
this sort of situation that makes Pine 4.10's new behavior obnoxious
compared to that of 3.96.

Jim