[Pan-users] Re: Added new server, messages don't get marked read

[Duncan]

Scott I. Remick posted <address@hidden>,
excerpted below,  on Wed, 03 Dec 2003 23:16:41 -0500:

> Ok I must be an idiot, but I cannot figure out what I'm doing wrong.
> 
> I had 3 servers already and I added a 4th. On this 4th one, whenever I
> read messages, they don't get marked as read. The other 3 still work fine.
> I can manually mark messages as read, but reading them doesn't do it.
> 
> I can't seem to find any server-specific setting that could affect this.
> Am I just blind?

No.  There aren't any, well, except..
 
> I'm using Pan 0.14.2
> 
> The only thing special about this 4th server is that it's accessed via
> stunnel (4.04) because the server uses SSL and Pan doesn't support that.
> So I configured the server to be "localhost" and port 7000. It works
> otherwise, except for the messages not being marked read.

This is the "except.." part.  <g>  I think you may have inadvertently
barged headlong into another normally unrelated quirk of PAN, tho I don't
know enough about the details to be sure.  This would be its handling of
local folders, namely the pan.sent and pan.sendlater folders, and any
others you may have added.  These look to the majority of PAN code like
any other server.  The difference being there's a small code section
that adds the necessary glue to make it work locally rather than through a
remote network connection.

I don't know how it's implemented, as I'm not that far into coding, but it
may be implemented as a mini-server running on localhost.  Even if not,
you may have somehow made your stunnel config look similar enough to it
that PAN can't tell the difference, thereby triggering the behavior you
see.

Some (beta) versions ago, PAN temporarily lost the ability to
automatically mark read one's own posts, as they came back from the remote
server, and were read along with all the other posts.  As I understand it,
this is because Charles had attempted an experimental shortcut, displaying
the copy from the sent folder rather than actually retrieving the remote
copy, saving that bit of network traffic.  There were a couple issues with
this, including the fact that what one saw wasn't necessarily what the
rest of the world saw, if the post had been mangled in transit, and the
fact that due to the way PAN handles marking posts read, by tracking
server group sequence number, which of course wasn't the same in the local
copy, simply reading it didn't get it automatically marked as read.  One
had to manually use the mark as read feature, which would (apparently)
catch the local sequence number and use it to mark as read, to get it
marked.  With the problems, Charles decided that wasn't such a good
feature after all, even if it DID save a bit of bandwidth, and PAN
reverted to d/ling one's own posts just as any other, even tho
theoretically there was already a copy stored locally, and the issues were
resolved.

That's what made the connection for me with your problem.  I remembered
the problems with that getting posts to mark as read, and once you
mentioned using localhost, I jumped the gap and speculated that it had to
be related, tho of course it's possible I'm wrong.   PAN is somehow mixing
up the posts and trying to mark read posts in its own folders/groups on
its own "virtual server", which of course doesn't work, because the
folders/groups don't exist there, and if they did, the server sequence
numbers would probably be out of sync.    The problem with this theory is
why it wouldn't affect those that actually DO run a local server, INN or
whatever, and connect to it with PAN using a small cache and essentially
as an online only real-time reader.  I still expect it's this quirk,
however (unless it's the "other possibility" mentioned below), and that
PAN must somehow recognize those while it doesn't for whatever reason
recognize your stunnel config.

Here's a possible work around, tho I've never tried it and you may have to
change a couple other things if your configuration isn't standards
compliant in this area..  While localhost is normally specified at
127.0.0.1, an entire subnet is actually reserved by RFC standard.  If I'm
not mistaken, it's the entire class A 127.0.0.0/8 subnet, but you should
be safe at least within the Class C 127.0.0.0/24 subnet.  Therefore, what
I'd try would be setting up the tunnel on 127.0.0.2, or some such, instead
of 127.0.0.1.  Of course, you will have to set up both your stunhel
"server", and PAN, to use the .2 address rather than the normal .1
localhost address, but anyway, that's what I'd try.

The other possibility, perhaps more likely, as it wouldn't run into the
problem comparison with the local "real" servers such as INN, as the above
theory does, would be a simple file corruption issue.  Perhaps PAN's
tracking files for that server somehow got corrupted.  PAN keeps all its
local files in ~/.pan/data/ , with .pan of course being a normally hidden
file on Linux/Unix systems.  You could try (with PAN shut down, of course)
renaming/deleting the appropriate (un)sub.dat(.bak) files and the server
folder, then restarting PAN and re-d/ling the server group list,
resubscribing to the appropriate groups, and going from there, to see if
PAN now can mark messages read as normal.

I'd hope one of the two approaches above fixes the problem.  Please keep
the list/group (I read this list as a newsgroup using PAN, on the
gmane.org list2news gateway) informed of the outcome.  

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin