* Originally in FIDO_SYSOP
* Crossposted in FMAIL_HELP

Hi,

On 2016-09-01 12:39:26, mark lewis wrote to Wilfred van Velzen:
  about: "In need of a .msg  JAM utility 32 bit":

 WV>> Well, what can I say. The original author never made that function.
 WV>> And I never missed it, and there were no requests to implement it.
 WV>> Untill now that is. ;)

 ml> well, more like a resurgence ;) there were some requests some years back
 ml> but that feature didn't arrive before the maintainers changed...

... And all the requestors had left fidonet.

 WV>> But it would be nice to have for the DUPES area, so I can have auto
 WV>> maintenance on it. Deleting older than X days messages in the dupes
 WV>> area for instance...

 ml> it works good for the bad messages area, too... plus any special areas
that
 ml> an operator might wish to have selected netmails placed into...

Indeed.

 WV>> FMail has that function, but only to the hudson message base. That's
 WV>> probably the place in the code where I would have to implement it for
 WV>> the JAM message base. So it might be easier than I was thinking first.
 WV>> ;)

 ml> yep... i use some early object pascal code and use the same calls for
 ml> everything, no matter what message base format is underneath... it should
 ml> be easy to do something similar in FMail...

Unfortunatly the FMail source isn't setup that way. I get the impression it was
first build with only the hudson messagebase in mind, and JAM functionality was
later added.

 WV>> The one FMail dupe database in it's standard settings is big enough
 WV>> for me, but I could enlarge it in the config if I wanted to (or
 WV>> needed it)...

 ml> what i'm looking at is that neither one can hold three years worth of dupe
 ml> hashes...

I don't need that. Older mail is taken care of by the old-mail detection. I
have that set at 60 days, and works great. ;)

 ml>>> fixing the renumbering bug would make me overjoyed...

 WV>> I don't know anything about FastEcho. ;)

 ml> it is recently discovered... there's a forced renumber point that can be
 ml> set... it is specifically for the HMB because... well... HMB :)  but
 ml> seriously, it has to do with HMB limitations... the problem is that it is
 ml> also being used for JAM areas and that breaks certain functions (eg:
 ml> serving messages via JAMNNTPd)... i may have figured out one thing but
need
 ml> to find the time to verify...

And the source for fastecho isn't available, so it can't be fixed?

Bye, Wilfred.


--- FMail-W32 1.71.5.204-B20160823