Re: [Fetchmail-users] FM v6.4.20 - concatenated log lines

[Matthias A. <mat...@gm...>]

Am 09.08.21 um 17:48 schrieb Matthias Andree:
> Am 08.08.21 um 21:54 schrieb Matthias Andree:
>> Am 08.08.21 um 20:07 schrieb J.Edner:
>>> Hi,
>>> I've just compiled and installed Fetchmail 6.4.20 on my server and found
>>> out, that some log lines are missing a new-line at the end, so that they
>>> are concatenated as follows:
>>>
>>> fetchmail: 16 messages for XYZ at SERVERfetchmail: reading message
>>> XYZ@SERVER:1 of 16fetchmail: reading message XYZ@SERVER:2 of
>>> 16fetchmail: reading message XYZ@SERVER:3 of 16fetchmail: reading
>>> message ...
>>>
>>> I checked the source code and saw that a new-line seems to be missing.
>>> After I've applied this small patch all messages are correctly written
>>> to the log file again:
>>>
>>> ----------
>>> --- a/driver.c. 2021-08-08 17:06:53.756148421 +0200
>>> +++ b/driver.c  2021-08-08 17:09:20.231666827 +0200
>>> @@ -629,7 +629,7 @@ static int fetch_messages(int mailserver
>>>
>>>         if (outlevel > O_SILENT)
>>>         {
>>> -         report_build(stdout, GT_("reading message %s@%s:%d of %d"),
>>> +         report_build(stdout, GT_("reading message %s@%s:%d of %d\n"),
>>>                          ctl->remotename, ctl->server.truename,
>>>                          num, count);
>>> ----------
>>>
>>> The result looks as follows now again:
>>>
>>> fetchmail: 16 messages for XYZ at SERVER
>>> fetchmail: reading message XYZ@SERVER:1 of 16
>>> fetchmail: reading message XYZ@SERVER:2 of 16
>>> fetchmail: reading message XYZ@SERVER:3 of 16
>>> ...
> Got it.

And as an example to illustrate what 6.4.20 misses from its --logfiles:
the log messages should have looked somewhat similar to (POP3 does not
distinguish header/body sizes and just logs (12345 octets)):

fetchmail: 2 messages for mandree at courier (folder INBOX.fmtest).
fetchmail: reading message mandree@localhost:1 of 2 (4982 header octets)
(32 body octets) not flushed
fetchmail: reading message mandree@localhost:2 of 2 (4263 header octets)
(41 body octets) not flushed

so the NNN octets stuff, and what ultimately happened to the messages
("not flushed") is missing, and your patch isn't bringing this
information back.
(I was using "--keep", so "not flushed" was in order).