Discussion:
[bug-mailutils] movemail: needs more verbosity
Jean Louis
2017-03-15 07:58:41 UTC
Permalink
Hello Sergey,

I was in Tanzania, and now I am in Uganda, Internet connection speeds
are sometimes comparable to modem times with 9600 baud or similar. And
it breaks often.

movemail need more verbosity. The option -v is not showing enough
information.

What would be really helpful is:

- to show how many emails are there on server, before fetching them,
something like 0/18, then to update 0 to 1, and so on, until there
is 18/18, with 18 emails as example. That way, counting would be
visible, and not that it hangs forever in case of bad Internet
connection.

Anything that would show me the progress in fetching would be helpful.

Jean
Sergey Poznyakoff
2017-03-15 14:59:46 UTC
Permalink
Hi Jean,
Post by Jean Louis
- to show how many emails are there on server, before fetching them,
When given the -v option, movemail does exactly that. It prints

number of messages in source mailbox: NNN

before trying to retrieve any mails. If it doesn't, enable
additional debugging to see what's going on behind the scene. The

--debug-level='mailbox.prot,!trace6'

will show you the entire (IMAP|POP) transaction on the protocol level.
Post by Jean Louis
something like 0/18, then to update 0 to 1, and so on, until there
is 18/18, with 18 emails as example.
What you describe sounds like progress meter. As a diagnostic tool it
is of little (if any) value, but it can be implemented, of course.

Regards,
Sergey
Jean Louis
2017-03-15 15:14:32 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
something like 0/18, then to update 0 to 1, and so on, until there
is 18/18, with 18 emails as example.
What you describe sounds like progress meter. As a diagnostic tool it
is of little (if any) value, but it can be implemented, of course.
Yes, a progress meter would be nice. Imagine you have 100 emails,
after travel, or even 5000 emails. At least I would know how much is
left or what happened during the network connection. Connection get
broken. Imagine the frustration, waiting for minutes, half an hour,
just to realize too late that connection was broken.

By the way, if I stop IMAP connection on server, movemail is to
exit. But if the network connection breaks, for example, there is no
mobile network available, movemail is not exiting. Maybe you should
have detection when there is no connection?

Jean
Sergey Poznyakoff
2017-03-16 06:13:03 UTC
Permalink
Post by Jean Louis
But if the network connection breaks, for example, there is no
mobile network available, movemail is not exiting. Maybe you should
have detection when there is no connection?
If the remote end disconnects, movemail will surely exit. There is no
way NOT to detect this condition. On the other hand, what you describe
means that the connection remains established, but the remote party stopped
replying. That could happen, e.g., if the underlying transport
had initiated reconnection during the session, and received another IP
address. There's no other way to handle this, other than timing out.

Regards,
Sergey
Sergey Poznyakoff
2017-03-16 09:44:08 UTC
Permalink
Post by Jean Louis
Yes, a progress meter would be nice.
Please try the attached patch. It implements the -m (--progress-meter)
option for movemail, which does what you proposed. The patch is against
the recent stable version. Let me know if it works for you.

Regards,
Sergey
Jean Louis
2017-03-16 14:16:12 UTC
Permalink
Post by Sergey Poznyakoff
Post by Jean Louis
Yes, a progress meter would be nice.
Please try the attached patch. It implements the -m (--progress-meter)
option for movemail, which does what you proposed. The patch is against
the recent stable version. Let me know if it works for you.
Thank you.

Oh, I maybe use the development version, so patch did not succeed.

<DEV> root [ /sources/gnu/mailutils ]# patch -p1 < progress_meter.diff
patching file include/mailutils/iterator.h
patching file libmailutils/base/assoc.c
Hunk #1 succeeded at 507 with fuzz 2 (offset -7 lines).
patching file libmailutils/base/iterator.c
patching file libmailutils/base/opool.c
patching file libmailutils/diag/debug.c
patching file libmailutils/list/iterator.c
Hunk #1 FAILED at 205.
1 out of 1 hunk FAILED -- saving rejects to file libmailutils/list/iterator.c.rej
patching file libmailutils/mailbox/hdritr.c
Hunk #1 succeeded at 165 with fuzz 2 (offset -7 lines).
patching file libmailutils/mailbox/mbxitr.c
Hunk #1 succeeded at 168 with fuzz 2 (offset -7 lines).
patching file movemail/movemail.c
Hunk #1 succeeded at 29 with fuzz 1.
Hunk #5 FAILED at 950.
Hunk #6 FAILED at 1044.
Hunk #8 FAILED at 1080.
Hunk #9 succeeded at 1106 with fuzz 2.
3 out of 9 hunks FAILED -- saving rejects to file movemail/movemail.c.rej
Loading...