Hello Keith,
On Wednesday, December 18, 2002 at 6:16:41 PM you [KR] wrote (at least
in part):
[POP-locks]
KR> Has anyone seen this?
Yes and no.
The good news first: The Bat! ain't the culprit. No version of it,
neither past nor future versions are or will be.
No to the "yes" part of my answer: I've seen this several time, no
matter what mail client (MUA) is involved. It's a pure 'server side
issue' and if your tech support ain't able to figure out what causes
the problem (I don't mention they should offer a solution in the
first!) it ain't "first rate" in this case, I'm sorry.
The technical background:
If a mail for you gets delivered to your ISP's mail server (MTA) it is
stored somehow, somewhere. In your case this seems to be a 'Mailbox',
in opposite to e.g. a 'Maildir' or a database.
This mailbox contains all messages in a serial form. One following the
other. Export any Folder with two or more mails from The Bat! to 'Unix
Mailbox' and you get the very same.
So if two mails come in the box gets "locked", the first mail is
written (stored), the lock is released and the second delivery process
is able to store the second mail. Else both processes would write
"mixed" and therefore inconsistence would be the result.
A 'POP-lock' is similar. Your POP3-server (the ISP ones) "locks" the
mailbox for (temporarily) no new messages being delivered, but held in
queue, until you finished fetching your mail. Why? Imagine the
POP-server-process gets told to hand out message #19.
You have 18 stored. w/ a lock he can _for sure_ tell you: there're
only 18, go away. w/o a lock he'd have to have a look if the mailbox
file changed. And yes, it is!!! So it streams msg #19 to you ... but
you read the mail, it's cut in the middle of a line. The delivery
process had stored (written) only half the message when your
POP-server decided to hand this message out ... *tztztztz*.
So this lock makes sense (for Mailbox files. Maildir, MH and DB for
example work different in storing mails and therefore can avoid the
lock.).
Well, when is the lock established? It's established after you've
authenticated successfully and the POP3-server know what mailbox file
to deal with. When is it released? It's released after you (your MUA)
have sent a 'QUIT' command to tell the server: "OK, this session is
over.".
How is it established? There're two possibilities:
1.) A file locking. The process tells the system to lock this file and
don't let any other process write (or even read) it.
As for example NFS, a "Network File System" does not handle file
locks properly (or even is completely unable in prior versions),
but chances are high the storage space for mail boxes is separated
from the server itself and therefore included "remotely" this
ain't practiced.
2.) The POP3-server copies the whole mailbox file to a temporary file
and copies it back after finishing the session.
Every other process dealing with mail (a concurrent POP3-process
or a delivery process) checks for this second file and "knows"
it's a 'lock' by the naming scheme (e.g. '8o4q-skup' mailbox file
becomes '.8o4q-skup.lock' lock file) and where this lock belongs.
If your POP3 session fails, e.g. because your connection was dropped
the server removes the lock in a way no changes to your "real" mailbox
are done. Means: even if you've already received some messages and
deleted them they're copied back to your mailbox file, for
consistence. If your mailbox is big enough and the servers load too,
this might take some time, from seconds to minutes. It depends.
If you try to authenticate and retrieve your mails while the "store
back" process is ongoing you're getting the "POP box locked" error,
because the lock file exists until the last bit is written back.
But there's another reason why this lock might stay: your server
didn't recognize the connection dropped. The POP3-process was not told
by network layer the connection ain't established anymore. This might
either be a intermediate proxy that did not close the connection yet
or any other network problem, there're many that are imaginable.
In this case the POP3-process "thinks" you're still connected and your
attempt to log in is a "concurrent login to the same mailbox" (from
its POV).
So your solution is to wait the 'timeout', usually around 10 minutes,
before trying again. It's no "real" solution, but the only thing you
can do at the moment. And this is the point why your support ain't
"first rate". They should be able to see whether the POP3-process is
"in moving back the lock file" or it is "assuming an alive
connection". In the former case the original mailbox file would grow
and grow, albeit the lock file still exists. This is an indicator the
server is copying the mails back.
In the latter case they should be able to see in log files and with
the help of 'netstat' your connection is assumed to be "still open"
and could try to figure out if there's a "point of failure" in their
network that might cause net congestions.
If you have any proxying software, like Wingate, SpamPal or any other
software that "inspects" or "handles" your POP3 connections installed
I'd deactivate it for testing if this might be the culprit. A not to
seldom seen candidate is for example NAV.
If you can exclude anything on your side of the internet connection
your ISP, respective its tech support, should be able to drive an
"observed POP3 session" to hunt down systematically the possible cause
of your trouble, in no case it is The Bat!. The Bat! recognizes if a
POP3 session is still active and refuses to open a second, concurrent
one, and therefore can't be the source of all this evil :-)
--
Best Regards
Peter Palmreuther
(The Bat! v1.62 Beta/17 on Windows 2000 5.0 Build 2195 Service Pack 1)
To save a single life is better than to build a seven-story pagoda.
________________________________________________
Current version is 1.62 | "Using TBUDL" information:
http://www.silverstones.com/thebat/TBUDLInfo.html
