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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
