Committed fix to Horde 3.0.5 and HEAD.

Using uw-imap:

I deleted the file (Tree.php), then retrieved a fresh copy from CVS. I 
think I got the right one (it looks like all of the previous 
modifications for this bug had been removed). I then made the change 
requested to the _getList function (to check the delimeter), and 
everything is working. Thanks!

*Perfect*



I commented out the "fixes" to _addLevel completely (so it's back to 
the way it was before I ever reported the bug), and just did this fix 
in _getList and it's a perfect fix.



It also now causes other folders to not show any possibility of 
expanding, whereas with the other fix it showed [+] beside boxes even 
though they couldn't be expanded - so it seems this is the better fix.



Hopefully this works for uw-imap users!



Eli.

Eli, in _getList(), can you try changing this line:

if (!empty($box->name)) {



to:



if (!empty($box->name) && !empty($box->delimiter)) {



As far as I can tell, folders that don't contain a delimiter must 
(obviously) be in the base level.  And INBOX should be the only folder 
that doesn't have a delimiter.  And we specifically add INBOX to the 
base level in IMP_Tree:: so ignoring it in _getList() will not prevent 
us from seeing INBOX in the base level.

Fix doesn't work for my issue.  The parent of the INBOX folders is 
always empty, thus it skips your alternate fix.



Is there no way to access the current delimiter for the folder it's 
about to expand?  If you can, can we not just agree that a folder with 
no delimiter should not be expanded?



Not expanding folders called INBOX means nobody can have a custom 
folder called INBOX anywhere except the main parent one - probably 
will never be an issue, but if someone does it, they'd wonder what's up.

Fixed for me (with uw-imap). Thanks!

What I posted on imp@:



Long story short - UW-IMAP will of course have it's INBOX flagged as 
\NoInferiors in a default mailbox setup since the INBOX normally lives 
in a totally different directory (i.e. /var/spool/mail vs. ~mail) from 
the user mailboxes.  So we can't use NOINFERIORS as a check.  Instead, 
just catch the case when we are trying to add 'INBOX' at a level other 
than the base level and skip this case if it occurs.

Allright, second attempt at this to make this re-work with UW-IMAP:

http://cvs.horde.org/diff.php/framework/IMAP/IMAP/Tree.php?r1=1.67&r2=1.68&ty=u



Please provide feedback as to whether this works.

Yes this fixes the problem :)  It is in fact the exact same line I 
found to modify to hack up a fix, however at the time I did not think 
to use the noinferiors flag (my fix was just to not look deeper in to 
any box called INBOX - certainly not useable by everyone).



I too do not know if the IMAP server is breaking RFC's, however I have 
submitted the operation of their IMAP server as a bug in hopes that 
they correct it.  I see no reason why their folders should have a 
"fake" folder called INBOX in them.  Their choice to do so also causes 
Horde/IMP to think that every folder has a child when viewing the 
folder tree, though thankfully it shows nothing when you try to expand 
it, and causes no errors.



It appears this has squashed the bug (for now! :) )



Thanks!



Eli.

Upon further review (after reviewing RFC 3501, Horde code, etc.) I 
still can't figure out if your IMAP server is breaking RFCs or not.  I 
will say that my IMAP server, nor pretty much anyone else's, is doing 
this.  However, it probably is a pretty smart idea to put in a 
NOINFERIORS check if not just for the simple reason that it doesn't 
break anything currently working and because it will most likely fix 
your problem.  So, can you take a look at the following patch:

   
http://cvs.horde.org/diff.php/framework/IMAP/IMAP/Tree.php?r1=1.64&r2=1.65&ty=u



and see if this fixes your problem?

I forgot to mention, I am using:



Horde v3.0.3

IMP v4.0.2

INGO v1.0.1

Turba v2.0.2

I have confirmed that Horde (though, I use Horde just for IMP, but 
from what I can tell the bug is in the underlying Horde IMAP classes) 
has a bug that:



1) Ignores the LATT_NOINFERIORS flag for folders.

and/or

2) Ignores that the folder "delimiter" is empty() for subfolders that 
it should not query.



I was able to confirm the bug by writing a very simple PHP script 
which lists IMAP folders.  I was able to duplicate the bug that IMAP 
does by incorrectly formatting subfolder queries.



What I mean by that is, if you have a folder called "Blah" in the 
parent list (and it  does not have the LATT_NOINFERIORS flag and does 
have a delimiter) and you try to list folders under it, you would 
query "Blah/%" for example (assuming / is the delimiter).  If that 
query yeilds another box called "Foo" (that also does not have the 
LATT_NOINFERIORS flag and does have a delimiter), you should be 
querying "Blah/Foo/%" next time.



However, it appears as though Horde is ignoring the parent folder when 
looking for subfolders of subfolders.  If it does this, when it sees 
"Foo", it then issues a query for "Foo/%".



In my particular case, it was in fact that the subfolder "Foo" (as an 
example) did  have the LATT_NOINFERIORS flag set as well as a 
delimiter set, so it should not have been queried (for two reasons).   
Because it was also improperly querying the subfolder, it was causing 
an infinite loop which probably nobody ever encounted due to the weird 
way my particular IMAP daemon works (SmartMax IMAPMax5).



My problem is because the IMAP daemon reports that beneath every 
folder, there is another folder called "INBOX".  This "INBOX" 
subfolder has the LATT_NOINFERIORS flag set and does not have a 
delimiter so it technically should not have been queried, but it was.   
That caused it to query "INBOX/%" (rather than "Trash/INBOX/%" for 
example).  This then caused the IMAP daemon to report a folder called 
INBOX under the INBOX folder, which caused an infinite loop.



If you take in to consideration the LATT_NOINFERIORS flag, the loop is 
stopped because the INBOX subfolders apparently all have that flag set.



If you take in to consideration the presense of the folder delimiter 
(for the folder you're querying), the loop is also stopped because the 
subfolders do not have a delimiter.



If you take in to consideration both cases, the loop is also stopped.



I have attached my test script (minus IMAP credentials that query my 
IMAP server).  The code may not be streamlined, but it demonstrates 
proper IMAP folder querying.



Eli.