Aloha Timo.
I had some further looks into the folder corruption issue
and it looks like non-blocking routines are being used.
Could it be possible that you are setting the istream to
non-blocking and that influences the ostream's/iostream's
timeout_msecs settings?
I got rid of the problem by using your pread() patch and
doing seeks on output in mail_storage_save() and write_func().
Because ostream-file.c/_read() is somehow thinking
ostream is non-blocking I had to do a call to
o_stream_flush() after writing the body, too, or
else a stray llseek() on input would make me write
the body to a very unfortunate position in the file.
io_add() is not being used, but the last bits of data
were still just being written to an iov and write()
was called only after some other operation.
At 19:15 16/10/2003 +0300, Timo Sirainen wrote:>On Thu, 2003-10-16 at 19:06, Andreas Jaekel wrote:
> > Concerning the problem of copying within one folder...
> >
> > I'm still not sure it's not a problem I created myself,
>
>No, it's with mbox too.
>
> > but I think it's caused by the use of the buffered IO
> > routines in ostream-file.c ... you use io_add() to schedule
> > write operations for later while simultanously reading
> > new chunks from the very same file. This seems to
> > confuse dovecot and make it write the copy to the
> > strangest locations. I think when working within one
> > folder I should use either blocking IO or a lot
> > of calls to o_stream_flush()... what do you think?
>
>I think it is using blocking I/O? I'm not actually sure if Dovecot ever
>really uses the io_add() there anymore..
>
>mbox-save.c:
> ctx->output = o_stream_create_file(ibox->index->mbox_fd,
> default_pool, 4096, FALSE);
> o_stream_set_blocking(ctx->output, 60000, NULL, NULL);