Re: [PATCH] after gzgets(), Z_STREAM_END means EOF, not error

[David Bremner <david@tethera.net>]

Olivier Taïbi <oli@olitb.net> writes:

> As suggested by David Bremner in
> https://notmuchmail.org/pipermail/notmuch/2020/029288.html
> here is the patch for bug #3: after gzgets() returns NULL (meaning EOF
> or error), the error code Z_STREAM_END means EOF and not error.

> PS: out of curiosity, why bother with the --gzip feature in notmuch dump
> and restore when the user can simply pipe to/from a gzip/bzip2/xz/...
> command?

I believe the original motivation (in 2014) was to make the dumping
process more atomic. I guess you could dig up the mailing list
discussion from the  time if you were interested. I'd be reluctant to
remove the feature after 6 six years.

> PPS: apart from dump and restore (and the indirect use of xapian), it
> seems that the only other use of zlib in notmuch is in
> format_part_mbox() in notmuch-show.c, which is able to read a compressed
> email (it seems that dovecot has an option to write emails in maildir
> format in this way to save space).>  Do I understand correctly that
> notmuch does not support indexing compressed email, and if so what is
> the point of using zlib in format_part_mbox()?

No, that's not correct. Notmuch does support indexing gzip compressed
mail as of version 0.29. IIRC that part uses GMime streams to do the
decompression (probably also using zlib indirectly).
>
> diff --git a/util/zlib-extra.c b/util/zlib-extra.c
> index 623f6d62..2d2d2414 100644
> --- a/util/zlib-extra.c
> +++ b/util/zlib-extra.c
> @@ -47,6 +47,7 @@ gz_getline (void *talloc_ctx, char **bufptr, ssize_t *bytes_read, gzFile stream)
>  	    int zlib_status = 0;
>  	    (void) gzerror (stream, &zlib_status);
>  	    switch (zlib_status) {
> +	    case Z_STREAM_END:
>  	    case Z_OK:
>  		/* no data read before EOF */
>  		if (offset == 0)

As you say, the lib docs could be improved, but I guess the "zlib error
numbers" referred to as re the same as "Return codes for the
compression/decompression functions", in which case this makes sense.

It would be helpful to move the discussion not intended to be part of
the commit message after --- (see https://notmuchmail.org/contributing/
for details).

d