Re: [Pan-users] no longer can view sent articles

[Duncan]

David Chmelik posted on Mon, 1 Jan 2024 02:57:11 -0000 (UTC) as excerpted:

> I can no longer can view sent articles selecting them just for many
> minutes only shows blank message pane (no headers, nothing).  Where can
> I find these in ~/.pan2 in case I need to review?

So pan's sent folder is managed as a (pseudo-)group.

Just as with other groups, messages in it are actually file-named by 
message-id (which pan assigns before posting and saving) and stored in 
article-cache, with selected information (message-id, author...) indexed 
in the groups/<group-name> file.

While this makes pan's code simpler as the same message-management code-
path is used -- no special treatment or code-path, it does have at least 
three drawbacks (tho 2 and 3 can be alternatively viewed as flip sides of 
the same one depending on your configured cache size and behavior):

Drawback 1: Because sent is a pseudo-group messages can't actually be 
downloaded -- they're (apparently) indexed once upon pan startup, so 
messages posted in the current pan session do not appear, only those from 
previous sessions.

Unfortunately that makes it difficult to refer to a message you just sent 
in another posted in the same session (and possibly for previous sessions 
as well, see drawback #3), at least by looking it up in sent messages. 
=:^(  Fortunately, if your server is processing posted messages fast 
enough a work around is doing a new headers-fetch so the message appears 
from the news server in the targeted newsgroup, allowing you to view it 
that way.

Drawback 2: Because pan stores by message-id, when you view your own 
messages on the targeted newsgroup, it's reasonably likely (at least 
initially, see below) that pan will still have the message as you sent it 
in-cache and will show it, instead of the message that everyone else would 
see, with headers such as x-trace, etc, that your news server likely 
adds.  In addition to missing those, if there was a transmission error 
you're unlikely to see it (again, at least initially), because you're 
seeing the copy cached locally as the message was sent, not the copy the 
server got (with the error) that you might have /thought/ you were 
downloading to check.

(On the flip side, if the message wasn't posted for some reason, it's 
likely possible to restart pan so it shows up in sent messages, or worst-
case dig it out of cache directly, allowing you to copy out the content, 
edit it if necessary to fix the error the prevented the posting, and 
resend in another message.  But again, the caveat is the next drawback...)

Drawback 3: Because pan only shows last-session and earlier posts in sent, 
if you have a small enough cache configured and enough activity that pan 
is actively expiring current-session posts from its cache, those messages 
may be expired from cache before the session is done, so they never get 
indexed on restart.

Here note that pan's default cache size is pretty small, particularly if 
you're doing binaries at all, so the chances of expiry before sent 
messages ever get indexed on restart, with the default cache size, unless 
you're doing text only, are relatively high.

(OTOH, I always increase my cache size dramatically, for my text-instance 
pan to several gigs such that I'm effectively archiving stuff for years 
(servers are set not to expire messages either), back to when I started 
posting to lists like the pan list and then gmane in 2002 for some groups/
lists.  For my binary instance (which I don't use regularly at all, but 
it's there, separately configured) I have a cache size of tens of gigs, 
suitable to keep small binaries like images, small videos, and mp3s cached 
locally for several sessions.  (Typically I first sample, then erase 
obvious garbage and download to cache what's interesting, before a final 
local-only processing pass that saves off permanently or deletes if I 
decide it's not interesting enough to save after all, meaning a cache 
that's too small and expires before I get to this step doesn't work.)  If 
I did large-binaries like high resolution full-length movies or TV series 
and/or full size ISO images, at least with the same strategy I use for 
smaller binaries, I'd probably want a cache size in the hundreds of gigs 
if not tibibytes... and would accordingly need a news server plan other 
than my unexpiring 1 TB block account that I've not had to renew in 
years.)

Similarly, if you have preferences > behavior > article cache > clear 
article cache on shutdown, checked... I *believe* sent will always appear 
empty (except in the case of a crash when it didn't get to clear the 
cache) because the article cache will be emptied before pan ever reindexes 
sent on startup.  (And pan's per-server message expiry options probably 
come into play here as well.)

This is likely what you're seeing, either pan emptying cache on shutdown 
if you have that option checked, so there's never any sent items to index 
on restart, or such a small cache that pan is expiring them before 
shutdown and restart, with the same nothing-there-to-index on restart 
result.

On the flip side, if it's not in-cache but did get posted, that means if 
you download the message from the group you posted it to, you'll get what 
everyone else does, complete with headers added by your server, any in-
transit posting errors that resulted in the message not being what you 
intended, etc.  But you'll have to do that via the group posted to, not 
sent messages, which likely never got to index it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman