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(a...@exemplo.com.br): Panic: file istream.c: line 96 (i_stream_read): assertion failed: (stream->eof) Jan 27 09:52:21 brc dovecot: IMAP(a...@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 <t...@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).
