From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: If I postpone a Reply, Pine never marks it as answered.
Status: RO
X-Status: 



This is a known limitation of the current release of Pine. When you
postpone a composition, Pine does not have any way to keep track of which
message was being replied to (or that it was a reply at all). This
limitation will be removed in a future release. 

From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: "Folder Format Invalidated (consult an expert), aborted"
Status: RO
X-Status: 

                                       

The message "Folder Format Invalidated (consult an expert), aborted" means
that Pine was reading your mail folder, and at the point in which it
expected a start-of-message header line, it found something else. 
   
The ``format invalidated'' condition can happen in one of three ways: 
    1. bad data exists at the beginning of the folder. 
    2. data was appended to the folder after Pine initially read it, and
       the new data did not begin with a start-of-message-header. 
    3. the folder was modified without Pine being aware of it. 
       
All three problems are generally caused by software external to Pine. 
   
Condition (1) can be determined by whether or not the problem repeats
itself after restarting Pine. If restarting Pine does not make the problem
go away, then you need to look at the actual file for the folder and see
what is wrong with the very first line. In particular, make sure that
there are no blank lines at the beginning of the file and that the first
character of the folder file is a capital ``F'' , the second an ``r'', the
third an ``o'', etc.  In the case of an INBOX, you may want to rename the
folder so that new mail can be delivered while repairs on the corrupt
folder are being done. 
   
Condition (2) may be caused by a mail delivery process (e.g. /bin/mail)
which writes some characters other than ``From '' at the beginning of the
new data. 
   
Condition (3) is caused by another program manipulating the mail folder
without following the normal folder locking protocols.  This is a general
problem on UNIX. 
   
Conditions (2) and (3) have also been known to occur when accessing
folders via NFS, if the information returned by the stat() and read()
system calls do not correspond with each other as a result of NFS
attribute caching. 
   
Restarting Pine on that folder always clears conditions (2) and (3). If
the problem is chronic, it may be worth an investigation to determine its
cause. Usually, it is due to the misbehavior of some external software.
The reason why Pine gives up with conditions (2) and (3) is that it does
not want to risk damaging user data by guessing what is right. Pine never
writes to the folder unless it is absolutely sure it knows what it is
doing. 
   
There are some steps which can be taken to reduce the risk of these
conditions coming up. Some of these steps may require the assistance of
your system adminstrator (or whomever it was that built and installed Pine
on your system): 
    1. Use IMAP instead of NFS to access remote folders. Problems with
       locking over NFS are perhaps the single most important cause of
       user difficulties.  Using IMAP eliminates this class of problem.
    2. Consider enabling the mbox driver in Pine. If the mbox driver is
       enabled, mail is transferred from the /usr/spool/mail mail into a
       file called mbox in your home directory, if mbox exists. The home
       directory mbox file is then your INBOX. This has the advantage
       that Pine and the mail delivery system are less often in
       contention for the INBOX, and never both trying to update it.
       Pine only empties the /usr/spool/mail file, it never tries
       updating it. 
    3. Be careful not to run other programs that modify your folders
       while you are running Pine. Such programs may change the folder
       out from under Pine, and lead Pine to conclude that there is a
       problem with its view of the file. 

From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: What is folder locking and how does it work?
Status: RO
X-Status: 

                                       

Locks are used by Pine and other mail programs to prevent damage from
occurring to the mail file when multiple programs try to write to the file
at the same time. 
   
Because there are many different schemes of mail file locking used on
UNIX, Pine implements all of them. The result is a lot of complexity. 
   
There are several reasons why locking needs to be done:
   
    1. If you want to read the mail file, you want to make sure that no
       other process will modify the mail file while you are reading it.
       
    2. If you want to write to the mail file, you want to make sure that
       no other process is accessing the mail file while you are writing
       it.
       
    3. If you have the mail file open, you want to make sure that no
       other process can alter any of the internal contents of the mail
       file that you have read, but it is OK if another process appends
       new data to the mail file.
       
    4. If you want to alter any of the internal contents of the mail
       file, you want to make sure that no other process has the mail
       file open.
       
There are several mechanisms of locking:
   
     * The creation of a file which has the same name as the mail file,
       but with a suffix of ".lock" (for example, this lock for
       /usr/spool/mail/isma is named /usr/spool/mail/isma.lock). This
       file accomplishes locks (1) and (2) above. This is an exclusive
       lock. 
     * The use of an flock() with LOCK_SH on the mail file. This
       accomplishes lock (1), and prevents lock (2). Multiple processes
       can do this. 
     * The use of an flock() with LOCK_EX on the mail file. This
       accomplishes lock (2), and prevents lock (1). This is an exclusive
       lock. 
     * The use of an flock() with LOCK_EX on a file on /tmp. The file
       name used depends upon the version of Pine. This accomplishes
       locks (3) and (4). This is an exclusive lock. 
       
On SVR4-based systems, the lockf() subroutine or fcntl() system call it
used instead of flock(). It is rumored that this creates a kind of lock
file as well, but this has not been directly verified. 
   
_NOTE: flock() on BSD systems does not work over NFS, so only the most
basic .lock file locking -- locks (1) and (2) happen over NFS. On SVR4
systems, fcntl() locking attempts to work over NFS, but there are known
problems in the rpc.lockd daemon which have caused hangs if an application
beats on the mechanism too much (and Pine beats on it). All of the above
mechanisms work reliably over IMAP connections._
   

From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: What happens when two Pine sessions access the same mailbox at the same time?
Status: RO
X-Status: 

                                       

This varies depending on what format your folders are stored in. With the
default Berkeley format, the last session to open a folder will get full
access to the folder and the previous session(s) will be changed to
read-only access. When a folder is read-only, you will not see any further
updates to that folder until it is reopened with full access. Currently
the INBOX cannot be reopened without exiting and restarting Pine. With the
Tenex format, any number of sessions can simultaneously have full access
to a folder, with the exception that expunging is disabled. See "What is a
Tenex mailbox and why should I use it?" for more information. 

From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: Why did I get the message "locked, override in _XXX_ sec"?
Status: RO
X-Status: 

                                       

The message "locked, will override in _xxx_ seconds" occurs when Pine has
discovered that some other mail program claims to be accessing your mail
folder (i.e. _folder_.lock exists). This is a very low-level lock used by
programs such as the system mailer in delivering mail, and by certain
programs such as mail, elm, babyl, mm, etc. Supposedly, this lock is only
to be acquired and held for a very short period of time (less than a
second). 
   
It starts with 285 seconds, retries every second, and issues that message
every 15 seconds. The total period of time, 5 minutes, is the time that it
will keep on trying before it concludes that the lock is false -- that is,
that whatever program locked the folder forgot to unlock it (perhaps it
crashed) -- and Pine will go ahead and claim the lock for itself. 
   
This is not due to a conflict between two copies of Pine, since Pine
interlocks against itself in a higher-level fashion. 
   
_NOTE: On some systems with 14 character filename limits, attempting to
open a folder with a 14 character name (e.g. saved-messages) will trigger
this sequence. Folder names should be limited to 9 characters or less on
those systems._

From dlm@shivafs.cac.washington.edu Wed Aug 24 09:26:18 1994
Date: Tue, 10 Feb 95 15:40:48 -0800
From: The Pine Development Team <pine-faq@docserver.cac.washington.edu>
Subject: Why doesn't Pine recognize Content-Length header field?
Status: RO
X-Status: 


It would be a significant detriment to the performance of the Berkeley
format mailbox parsing code, as well as to Pine's behavior on normal
systems which do not use the Content-Length: header, if any attempt were
made to implement Content-Length:. 

There are many serious technical problems with the Content-Length: 
header, and we do not recommend its use.  Furthermore, we recommend that a
mail delivery agent such as our sendit or tmail tool be used that applies
smart quoting, as opposed to the ordinary BSD /bin/mail quoting of all
lines that begin with "From ".  We have installed such tools on all of our
systems. 

For example, one problem is that a system whose mailer does not implement
Content-Length: will also not enforce its validity should that header
appear. This offers significant potential for mischief.  Another problem
is that Berkeley format mailbox files which use the Content-Length: header
can not be edited with an editor such as emacs or vi without invalidating
the Content-Length: field.  If this problem is not a consideration at your
site, we recommend the use of the tenex format (mail.txt), which is also
length tagged but in a much more efficient fashion. 

From our perspective, these problems outweigh any possible benefit of
supporting Content-Length: in Berkeley format mailbox files.  At the
present time there are no plans to do so. 
 
