Michael Haggerty wrote:
> --- a/imap-send.c
> +++ b/imap-send.c
[...]
> @@ -772,13 +767,10 @@ static int get_cmd_result(struct imap_store *ctx,
> struct imap_cmd *tcmd)
> !strcmp("NO", arg) || !strcmp("BYE", arg)) {
> if ((resp = parse_response_code(ctx, NULL,
> cmd)) != RESP_OK)
> return resp;
> - } else if (!strcmp("CAPABILITY", arg))
> + } else if (!strcmp("CAPABILITY", arg)) {
> parse_capability(imap, cmd);
> - else if ((arg1 = next_arg(&cmd))) {
> - if (!strcmp("EXISTS", arg1))
> - ctx->gen.count = atoi(arg);
> - else if (!strcmp("RECENT", arg1))
> - ctx->gen.recent = atoi(arg);
> + } else if ((arg1 = next_arg(&cmd))) {
> + /* unused */
Neat. Let me try to understand what was going on here:
When opening a mailbox with the SELECT command, an IMAP server
responds with tagged data indicating how many messages exist and how
many are marked Recent. But git imap-send never reads mailboxes and
in particular never uses the SELECT command, so there is no need for
us to parse or record such responses.
Out of paranoia we are keeping the parsing for now, but the parsed
response is unused, hence the comment above.
If I've understood correctly so far (a big assumption), I still am not
sure what it would mean if we hit this ((arg1 = next_arg(&cmd))) case.
Does it mean:
A. The server has gone haywire and given a tagged response where
one is not allowed, but let's tolerate it because we always have
done so? Or
B. This is a perfectly normal response to some of the commands we
send, and we have always been deliberately ignoring it because it
is not important for what imap-send does?
Curious,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
