Re: [Pan-users] Odd binary download issue - .msg file in download folder

[Duncan]

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