Dave posted on Tue, 16 May 2017 21:59:37 +0000 as excerpted: > Pan 0.141 Tarzan's Death (168b179 git.gnome.org/pan2; > amd64-portbld-freebsd10.3) > > Recently, pans behaviour has changed and since no one has mentioned it > here, I guess it's just me. > > If I download a binary, all the .msg files also appear in the download > directory. Since other FreeBSD ports have been updated and I usually > have the Pan port locked so as not to update with everything else (I > edit the max server setting and rebuild manually), I have since manually > fetched and rebuilt from source using FreeBSD ports, to no avail. > > It's most likely something external to Pan since the only symptom is > that after downloading and assembling the .msg file into the final file, > the .msg files are not deleted. The .msg files are owner:group > dave:dave, 644. The destination dir is dave:dave, 777 > > Anyone got any suggestions as to where to start looking? > > cd /usr/ports/news/pan && make run-depends-list
> /usr/ports/mail/gmime26-2.6.23 If it's a lib, it's almost certainly this one, which handles decoding, etc, but I suspect it's actually a pan option you've set... Note that pan has several choices in relation to "download". First off, the literal "download" is done by what pan refers to as caching, downloading the (raw) messages to local storage. This won't change the read status or save anything off (unless you have automated actions defined), simply download messages into article-cache , from which you can read them or save them off, later, without actually downloading them, because they're already stored (cached) locally. In the local cache the (raw) messages are stored as *.msg files. The catch to caching without immediately reading or saving is that by default pan's cache size is only 10 MiB. For binaries that's tiny, and attempting to download aka cache too many messages will cause pan to start deleting the oldest ones in ordered to allow new ones to be downloaded. If you've not read or saved what you've already downloaded, that's frustrating to say the least, particularly if your NSP account is a block account, aka pay by the download. So people (like me) that prefer this option normally need to set a far larger cache, often multiple GB, or just set it to TB (tho there might be some limit on 32- bit pan) and don't worry about it. The other alternatives are what pan calls saving. These don't directly relate to downloading at all but rather to saving off the already downloaded to cache messages, except that if you've not downloaded the messages to cache already, they obviously must be downloaded to cache before they can be saved, and pan will do that transparently. But there's actually three options for saving, displayed as a drop-down menu in the save dialog. It's this that I suspect you have changed, since pan remembers your last choice and uses it as the default for further saves as well. The three options are: * Save attachments * Save text * Save attachments and text Save attachments will decode and save the attached files to the configured save location. Save text will save the raw text-encoded (or yenc-encoded) *.msg files, basically copying them out of cache so they don't get deleted in ordered to make room for more. Save attachments and text will save both. My guess is that you selected this, either deliberately for some post or another, or accidentally, and pan has simply remembered and continued to use this option, so you're getting all those raw text-encoded *.msg files in addition to the decoded attached files. Check that and see. If that's not it, then there really must be a change in pan's behavior, but I suspect that's it as it would explain no one else seeing the problem, tho obviously someone would need to be first to report it if there was indeed a change. Meanwhile, off the direct topic but... Two additional points, the first one still directly pan related, the second somewhat less so: Point one: Pan's max server setting. I presume you mean the max connections per server setting, because if pan has a maximum number of servers it'll allow to be configured, I'm definitely not aware of it, and it would strike me as rather odd... You're aware that the four connections per server max is simply in the GUI, correct? If you manually edit servers.xml and set 50 connections per server, pan will be happy to use them. =:^) You'll just need to avoid OKing any changes to that server in it's GUI server config dialog in ordered to keep the manually set connections setting, and once you have it setup the way you want, that's normally easy enough. The reason it works that way is due to GNKSA. While some find particularly two points of GNKSA to be outdated, namely the connections limit and the ban on HTML, the question of whether to keep pan GNKSA strictly compliant did come up here a few years ago, and the overwhelming consensus seemed to be in favor of maintaining strict compliance. FWIW I believe that was in part because there /was/ this manual override to the connections limit, and in part because people (including me) appreciate GNKSA compliance as part of pan's unique character now, and are afraid that if we compromise, the wall will be broken and pan will eventually start doing HTML, encouraging top posting, and all the rest, basically losing its distinction and the reason many regulars choose it as opposed to some other news client. Anyway, that does give you a choice. If you prefer the GUI config method and just want to be able to set whatever number of connections you want there, a user-applied patch for that is appropriate, as it's unlikely to be applied upstream and if it ever is, a number of pan regulars may move on. But if you just want your more-than-four connections, you can edit servers.xml manually to set that, and avoid the patch. And that works with GNKSA, because pan doesn't allow setting more than four connections in its GUI. GNKSA mandates nothing in terms of forcing a client to cap at four connections if someone has manually edited its config to above that, so pan is free to honor the requested number of connections above four, if a user has chosen to set it that way manually. (And as I said, it's likely in part /because/ of that, that the list voted to continue to maintain strict GNKSA compliance. Otherwise, it's quite possible the GUI could set any number of connections per server now... and maybe pan would do HTML, and not warn about top posting, and etc, too. And maybe if changed to that degree, regulars like me would move on, too, so to the degree that old crusty regulars like me are still considered a benefit, that's probably a good thing.) So you can keep patching if you want the GUI choice, but if you just want more than four connections, you may find it easier to edit the config manually and skip applying that patch. =:^) Point two: You mention FBSD ports, and choosing to lock pan and build it manually, so you can apply patches. That's of interest to me as a gentooer, since long ago, over a decade and a half ago I guess now, gentoo's build system, with its default portage package management and build client, was based on fbsd's ports system. Obviously that's quite some time ago and it's likely fbsd's ports have changed substantially since then, as I know gentoo's package management has (it has actually had three choices as package management client for some time now, for instance). Your mention of locking and manual building struck me because, while it's still /possible/ to do that with portage (which I still use despite the other two choices), these days, if all that's needed is to apply a patch or two, all you do is drop the patch in the appropriate patch tree and it gets automatically applied to the package as it's normally built -- no need to take it out of the normal update process and apply patches manually. And I routinely do that with a number of packages, including pan. I have some patches that I've been applying to one package or another that way for years. If at some point they get updated upstream so the patches no longer apply, the build aborts and I get to dig into what changed upstream and whether I still need my patch or not, but other than that, if I've dropped the patch in a general package dir and not in a specific package version dir, it continues to apply to each new update automatically, without me having to think about it further. So I'm just wondering, ports doesn't have something similar to automate applying your own patches? Or you already use it and simply didn't mention it? Or you /could/ use it and simply choose not to. Regardless, respect for choosing to apply your own patches, manually or automated. Just wondering. -- 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
