[Dovecot] Pine and prefix - LIST command bug?

[Chris Wakelin]

Timo Sirainen wrote:
> On Mon, 2005-03-21 at 13:11 +0000, Chris Wakelin wrote:
> 
>>On Mon, 21 Mar 2005 14:38:19 +0200 Timo Sirainen <tss at iki.fi> wrote:
>>
>>
>>>On 21.3.2005, at 14:09, Chris Wakelin wrote:
>>>
>>>
>>>>Having said that, Pine is still getting confused. This time it's trying
>>>>'LIST "" ~/mail' and getting no results whereas UW-IMAP gives '* LIST
>>>>(\NoSelect) "/" ~/mail'.
>>>
>>>How about if LIST "~/mail/" "" returned ~/mail/ even if the namespace 
>>>is hidden?
>>
>>If we're imitating UW-IMAP then LIST "~/mail/" "" should return "~/".
> 
> 
> Yes, but I was thinking we could do it a bit more easily by changing the
> behavior to be different from UW-IMAP, as long as Pine worked with it. I
> don't think the reply above would necessarily be against IMAP spec,
> because it would be correct for visible namespaces.
> 
> 
>>I guess the second Pine problem is that it tries to make sure the 
>>"~/mail/" prefix exists and tries to create it if it doesn't. I'm not 
>>sure whether it has a right to expect this to work.
> 
> 
> It does if the first reply returned ~/. That's why I wanted it to make
> return ~/mail directly so I wouldn't have to create LIST matching for
> namespace prefixes too :)
> 
> Did you try if the patch in previous mail happened to work? If not, I
> guess I'll have to add that prefix-LISTing code..

I've just tried it, and the same happens; PC-Pine (this time) is trying

LIST "" ~/mail/

and getting no matches, then when you answer yes to the question "Exit, 
saving changes and creating path?" it tries

CREATE ~/mail/

which presumably fails. It then disconnects with "IMAP connection broken 
(server response)".

It looks like Dovecot is crashing on the "CREATE" command:

dovecot: Mar 28 12:14:59 Error: IMAP(vis99003): file strfuncs.c: line 
165 (p_strndup): assertion failed: (max_chars != (size_t)-1)
dovecot: Mar 28 12:14:59 Error: child 28188 (imap) killed with signal 6

There's a core file for imap which gives

...
(gdb) bt
#0  0xff21c724 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff1b5a84 in abort () from /usr/lib/libc.so.1
#2  0x5ea2c in i_internal_fatal_handler (status=490288, fmt=0xffbef238 "",
     args=0x5ea10) at failures.c:374

if that's any help!

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094