Hi Timo....
Making my tests with the body and head separately (splited in 2 files and concatenated with the i_stream_create_concat), getting some errors that I do not understand. I did not create the plugin, the changes is in maildir-mail.c. Is the same that I write in the beginning of the email. The error happens when there is attachment in the message, with a attachment with 12K of size, i got the errors... I got these messages from /var/log/mail
Jan 27 09:52:21 brc dovecot: IMAP(alex@exemplo.com.br): Panic: file istream.c: line 96 (i_stream_read): assertion failed: (stream->eof) Jan 27 09:52:21 brc dovecot: IMAP(alex@exemplo.com.br): Raw backtrace: imap [0x80eb910] -> imap [0x80eb96a] -> imap [0x80eb21a] -> imap(i_stream_read+0x14b) [0x80f0b0b] -> imap(i_stream_read_data+0x1d) [0x80f0b8d] -> imap [0x80e3c5f] -> imap [0x80e4dfe] -> imap(message_parser_parse_next_block+0x2a) [0x80e3daa] -> imap(message_parser_parse_body+0x2c) [0x80e3f0c] -> imap [0x809e68e] -> imap [0x809e7cf] -> imap(index_mail_get_special+0x3f9) [0x809ecf9] -> imap [0x8088b07] -> imap [0x80666a5] -> imap(imap_fetch_more+0x104) [0x8067304] -> imap(cmd_fetch+0x282) [0x805f012] -> imap(cmd_uid+0x7f) [0x806377f] -> imap [0x80643dc] -> imap [0x806448b] -> imap(client_handle_input+0x3f) [0x80645df] -> imap(client_input+0x5f) [0x806514f] -> imap(io_loop_handler_run+0x110) [0x80f4620] -> imap(io_loop_run+0x28) [0x80f36e8] -> imap(main+0x738) [0x806d628] -> /lib/libc.so.6(__libc_start_main+0xd8) [0xb75d47c8] -> imap [0x805d071] Jan 27 09:52:21 brc dovecot: dovecot: child 24407 (imap) killed with signal 6 (core dumps disabled)
Why this happens ? The size of message dont change, it is only splited.
2010/1/20 Timo Sirainen tss@iki.fi
On 20.1.2010, at 20.45, Alex Baule wrote:
Timo Sirainen send to me this modification, in src/lib-storage/index/maildir/maildir-mail.c
struct istream *full_input[3]; full_input[0] = i_stream_create_fd(fd, 0, TRUE); full_input[1] = i_stream_create_fd(fd1, 0, TRUE); full_input[2] = NULL; input = i_stream_create_concat(full_ input);
This is necessary because my Header and Body is splited. This modification works fine.
My question is:
There is a way to do this with a plugin ? I dont know how to implement this in a plugin, because i dont know what is the hook to change the maildir_open_mail functions. (this is the function with the modification above) .
It's similar to how zlib plugin does its work. You need to copy&paste enough code from it, so that you'll get to
static int zlib_maildir_get_stream(struct mail *_mail,
The important part of the code below it that replaces the maildir's istream is:
imail->data.destroying_stream = TRUE; i_stream_unref(&imail->data.stream); i_assert(!imail->data.destroying_stream); if (fd == -1) return -1; imail->data.stream = handler->create_istream(fd);So instead of handler->create_istream(fd), you'll use your own. Or actually IIRC you didn't even want to destroy the original stream, so instead of any of the above, you'd probably do something like:
old_stream = imail->data.stream; imail->data.stream = create_your_stream(old_stream); i_stream_unref(&old_stream);
Another question is: There is a seek function, in dovecot, and in zlib plugin, it is rewrite by another function, that use the "gzseek" to do the seek. My splited body will be encrypted, and the crypto no have seek, because the message will be encrypted. (if i open the message, decrypt and seek to some position, maybe work).
The seek function is really necessary to IMAP and maildir ?
Well, gzseek() doesn't work any easier. It can't directly jump to wanted position. When seeking forwards, it'll just read and uncompress data until it reaches the wanted offset. When seeking backwards, it'll go back to beginning and start reading and uncompressing from there. That's why there's the "marked" code in istream-zlib that tries to avoid the backwards seeks. You could maybe use something like that too, but you could also put the whole thing through i_stream_create_seekable() and Dovecot just keeps the whole message in memory (by setting max_buffer_size=(size_t)-1).