[Dovecot] A view quirks

Timo Sirainen tss at iki.fi
Thu Oct 16 19:12:47 EEST 2003


On Thu, 2003-10-16 at 17:14, Andreas Jaekel wrote:
> 1.
> 
> * OK dovecot ready.
> A = (<return>
> Connection closed by foreign host.

Fixed. It always disconnected if there was an error in the IMAP command
syntax.

> 2.
> 
> * OK dovecot ready.
> A001 LOGIN xxxxxx xxxxxx
> A001 OK Logged in.
> A002 COPY 1 INBOX
> Connection closed by foreign host.
> (segfault)

Fixed.

> 3.
> 
> [...]
> A003 SEARCH SUBJECT "test"
> * SEARCH 1
> A003 OK Search completed.
> A004 SEARCH SUBJECT {6}
> + OK
> "test"
> * SEARCH
> A004 OK Search completed.
> 
> I think these two searches should give identical results.

No. First you are searching for test without quotes. Then you are
searching for "test" with quotes. Correct way would be {4}\r\ntest, or
SEARCH SUBJECT "\"test\"".

> 4. (my current nemesis)
> 
> A002 CREATE bla
> A003 SELECT INBOX
> A004 COPY 1 bla
> A005 SELECT bla
> A006 COPY 1 bla
> * NO Internal error [2003-10-16 16:07:21]
> A006 OK Copy completed.
> 
> If I copy from the current folder to the current folder I get
> a scrambled mailbox and an error.  This might be selfmade, though.

Yeah. It's in my TODO list too. Problem is that it uses the same file
descriptor for both reading and writing and the seek offsets get mixed
up. This could be fixed by always seeking to correct position, but
that's a bit annoying since either you have to do it always (unnecessary
nearly always) or add some extra kludgy checks. You could also be just
reading with mmap() or pread() but I'm not sure if it's a good idea to
rely on them either.

> I'm currently trying to find this bug, but the various layers of
> [_oi]streams and callback and function pointer structs do not help :)
> I think the stream routines hide the mstream(istream(realstream(iostream)))
> and the ostream(_ostream(iostream)) behind the same file descriptor
> and the data gets written to the wrong position.

Yes, the stream stuff is kind of ugly and difficult to follow. Maybe
still has some bugs too.. Cleaning them up would be a good idea, but I'm
not sure if I know how. I don't think the class system is too bad
though, you can't do it much better with C.

> BTW: what exactly is "max_pos"?

You mean high_pos? It's .. um.. some kludge.. that I added to fix some
problem.. :) I think it went:

Normally "pos" contains the amount of data that has been read from the
underlying stream. But when you temporarily set a read limit, it has to
shrink "pos" as well or things break. So "high_pos" is there just to
remember what the "pos" was before any read limits.

It should work so that istream.c does every stream's buffering. The
istream-*.c then just provide a way to fill the buffer and seek around
in the stream.




More information about the dovecot mailing list