Closed Bug 680867 Opened 13 years ago Closed 13 years ago

Cannot create subfolder in IMAP mail

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: pe1chl, Unassigned)

Details

Attachments

(6 files)

IMAP logfile
11.41 KB, text/plain
Details
davee's IMAP log, annotated to show actions taken at each step
32.35 KB, text/plain
Details
davee's Screenshot 1 of 3, showing folder structure, esp. folder 'Foo' with existing subfolders
9.08 KB, image/png
Details
davee's Screenshot 2 of 3, showing immediate right-click on folder 'Foo', correctly presenting 'New subfolder...' option
13.95 KB, image/png
Details
davee's Screenshot 3 of 3, showing second attempt to right-click on folder 'Foo': it incorrectly omits 'New subfolder...' option
13.66 KB, image/png
Details
Log with patched UW IMAP
10.77 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110813 Firefox/6.0 SeaMonkey/2.3
Build ID: 20110813174900

Steps to reproduce:

Using an IMAP mail account on UW IMAPD.  This server supports subfolders that contain either messages or folders.
After browsing around mail folders for a while, right-click on a previously created folder that contains folders, the "new subfolder" item does not appear.
When starting from the top of the account and create a folder, that folder cannot be selected as a location to create the subfolder.


Actual results:

It is not allowed to create a subfolder at a location where this should be OK.
When shutting down and starting the program and as a first action create the folder, it works OK.   Only after some browsing through the folder list it suddenly becomes impossible to create a subfolder.


Expected results:

It worked OK at least in Seamonkey 2.0.12

Additional info:
the "mail.server.server1.capability" pref is now 541221 for this server.
this used to be 541217 in older versions of Seamonkey.
Maybe a change in this area has introduced this problem?
I see this same behaviour in Thunderbird 6.0, although in our case the backend IMAP server is Dovecot not UW-IMAPd.
I should add that there was no issue here in Thunderbird 3.1.x.  Unsure whether it existed in Thunderbird 5.0, because that wasn't the current version for very long and I made no attempts at folder creation during that short time!
kHasAuthOldLoginCapability is 4, which should be unrelated to this issue. The relevant pref is mail.server.serverXX.dual_use_folders. Other than that, we turn off creating of sub-folders if ImapNoinferiors is set for the folder, which is controlled by "\\Noinferiors".

When this happens to you (I'm not seeing it here), is it broken for just certain folders, or all folders?
For info, in my case with TB 6.0 at least, the issue does not goes away with a fresh profile.

When broken it appears to be broken for all folders as far as I can see.

Not sure what you mean about 'NoInferiors' - is that something which would appear somewhere in the TB profile, or somewhere on the IMAP server?
NoInferiors is something the imap server returns for each folder that can't have inferiors. Is the dual use pref set? you can check with the config editor, tools, options, advanced, general, config editor) and type dual_use.

Does the problem go away when you restart, like the original reporter?
Dual-use preference is unset:

user_pref("mail.server.server1.dual_use_folders", false);

So, like the original reporter says "Folders which can contain messages *OR* folders" (but not both).

I get exactly the same symptom as the original reporter in his "Actual Results" section: if, on starting Thunderbird I *immediately* try to create a new subfolder, I can do so.  However, once I do *anything* else (even just click the title bar of the application!), I no longer get the option to create a new folder.
In my case, dual_use_folders is false.  I have locked it to false in a lock_pref that is in effect for all users.  (as our mailserver does not support dual_use folders)
It looks like I can create a new folder after I have started the program, but once I click on the [-] or [+] to the left of the folder, to expand/unexpand the folder contents, I no longer can create folders anywhere within folders.
(not only in this particular folder but also not on other folders within the same account and even within other accounts hosted on the same server)

Is this linking to NoInferiors something that was introduced with this version?
I have used many versions of Seamonkey in this environment and this problem for me certainly is new, but of course it could be that UW-IMAPD has been returning a wrong value all the time, it just wasn't acted upon by Seamonkey.
If it's a long-undetected uw-imapd bug, then it's also a long-undetected dovecot bug!  I see same symptoms as Rob: clients set to dual_use_folders as false because the mail server (Dovecot using mbox backend) doesn't support dual-use.

Rob sees this bug with Seamonkey v. uw-imapd, I see it for Thunderbird v Dovecot, so I imagine it's something common to all IMAP code which needs to be looked at here.
Moving to MailNews Core::Networking IMAP since this appears to affect both Thunderbird and SeaMonkey.
Component: MailNews: General → Networking: IMAP
Product: SeaMonkey → MailNews Core
QA Contact: mail → networking.imap
Version: SeaMonkey 2.3 Branch → 6
I discussed it with a Thunderbird 5.0 user and he has the same problem.
Is there anything I, as an end-user with access to an appropriate IMAP server and ability to run some sort of debugging processes, can do to help get this bug fixed?
FYI.
(A) For \Noinferiors vs. \NoInferiors:
 - Correct one is \Noinferiors. See bug 561165 comment #8
 - UW-IMAP or some others had bug of "return wrong \NoInferiors instead of
   correct \Noinferiors".
 - A cause of "wrong \NoInferiors by UW-IMAP" is a bad string of \NoInferiors in
   6.3.8. LIST Command section of RFC 3501( http://tools.ietf.org/html/rfc3501 ).
   IIRC, errata for the bad string already exists, but it's not reflected to
   latest RFC 3501 yet.
 - AFAIK, UW-IMAP's bug was already resolved, but "return correct \Noinferiors"
   was optional. If default setting, wrong \NoInferiors was still returned
   in order to keep same behaviour as old versions for some IMAP clients
   who rely on wrong \NoInferiors.
(B) Bugs in which IMAP log of "wrong \NoInferiors in LIST response" is provided:
   Bug 410934, Bug 419780, Bug 561165, Bug 630784
Anyway, IMAP log is mandatory for diagnosis of your problems.
(In reply to Rob Janssen from comment #0)
> Using an IMAP mail account on UW IMAPD.  This server supports subfolders
> that contain either messages or folders.
> right-click on a previously created folder that contains folders,
> the "new subfolder" item does not appear.
> When starting from the top of the account and create a folder, that folder
> cannot be selected as a location to create the subfolder.

Some servers require "create foldername/" instead of "create foldername" if "folder contains subfolder only" instead of "folder contains mail only".
Can you create "folder contains subfolder only" by next?
(1) Create folder named "ABC/" via Tb's folder creation UI.
(2) Due to Bug 301714, subscribing of the new folder by Tb fails.
(3) Manually subscribe folder ABC via Subscribe of account's context menu.

If this kind of issue, workaround is;
  Create lowest level "folder contains mail only" since initial.
  - Create ABC/DEF/GHI in one step, instead of create ABC, ABC/DEF, ABC/DEF/GHI
  ABC         : folder contains subfolder only
  ABC/DEF     : folder contains subfolder only
  ABC/DEF/GHI : folder contains mail only

Note:
If you repeat unsubscribe/subscribe, Bug 520437 occurs. If garbled file/directory with suffix is created, clean up them to avoid unwanted future problems, please.
(In reply to WADA from comment #14)

Note the problem is just as described in my initial report and the comments from Dave Ewart,
and happens for every account independent of previous actions and existing folders.
I.e. there is no problem when the program is started and immediately a folder is created, the folder is created OK and it works OK.
The problem is not with creation of the folder, but with the UI of Seamonkey (and Thunderbird).
Once the folder tree has been navigated, the option to create a subfolder in a folder that can contain subfolders is removed from the UI.
Restart the program and a single subfolder can be created and works OK.
Attached file IMAP logfile — 
I created an IMAP logfile for the following test:
- a test account with existing folder ContainsFolders that has 2 subfolders SubFolder1 and SubFolder2.
- mail is opened and above structure is correctly shown
- right-click on ContainsFolders alows creation of a new subfolder
- new subfolder SubFolder3 is created and shows up OK
- right-click on ContainsFolders now no longer shows the option to create a new subfolder

The .mailboxlist for UW-IMAP shows:
INBOX
Mail/Drafts
Mail/Sent
Mail/Templates
Mail/Trash
Mail/ContainsFolders/
Mail/ContainsFolders/SubFolder1
Mail/ContainsFolders/SubFolder2
Mail/ContainsFolders/SubFolder3

I.e. the "folder that holds subfolders" is correctly created with trailing /

All of this done with Seamonkey 2.3.3
This IMAP log has been annotated to show what I was doing (or trying to do) at each step.  It includes both an initial successful attempt to create a new subfolder and then covers the time period when the 'new subfolder' option was not presented to the user, i.e. no logging information at that stage.
For info, my IMAP log and screenshots were carried out using:

- Thunderbird 6.0.2 for Windows;
- Dovecot 1.2.15 (from Debian 'Lenny') server-side.
After uploading the debug log and screenshots earlier today, I saw the notification that Thunderbird 7.0 was released.  This bug seems not to happen with Thunderbird 7.0, which is excellent.  I assume that the corresponding version of SeaMonkey may now also work: Rob, can you confirm?

In summary:

Thunderbird 3.1: OK.
Thunderbird 5: (Didn't test)
Thunderbird 6: BUggy as described above.
Thunderbird 7: OK.
(In reply to Rob Janssen from comment #16)
> Created attachment 563003 [details]
> IMAP logfile
> 
> I created an IMAP logfile for the following test:
> - a test account with existing folder ContainsFolders that has 2 subfolders
> SubFolder1 and SubFolder2.
> - mail is opened and above structure is correctly shown
> - right-click on ContainsFolders alows creation of a new subfolder
> - new subfolder SubFolder3 is created and shows up OK
> - right-click on ContainsFolders now no longer shows the option to create a
> new subfolder

Following flow is seen in log.
> mail.uw:A:SendData: 3 create "Mail/ContainsFolders/SubFolder3"
> mail.uw:A:CreateNewLineFromSocket: 3 OK CREATE completed
> mail.uw:A:SendData: 4 subscribe "Mail/ContainsFolders/SubFolder3"
> mail.uw:A:CreateNewLineFromSocket: 4 OK SUBSCRIBE completed
> mail.uw:A:SendData: 5 list "" "Mail/ContainsFolders/SubFolder3"
> mail.uw:A:CreateNewLineFromSocket: * LIST (\NoInferiors \UnMarked) "/" Mail/ContainsFolders/SubFolder3
> mail.uw:A:CreateNewLineFromSocket: 5 OK LIST completed
Your IMAP server looks to still have "bug of incorrect \NoInferiors instead of correct \Noinferiors". But it doesn't seem directly relevant to phenomenon you described, because Tb ignores the wrong \NoInferiors.

Following flow is also seen in log.
> mail.uw:A:SendData: 2 list "" "Mail/ContainsFolders"
> mail.uw:A:CreateNewLineFromSocket: * LIST (\NoSelect) "/" Mail/ContainsFolders
> mail.uw:A:CreateNewLineFromSocket: 2 OK LIST completed

List response is defined as \Noselect by RFC 3501.
> 7.2.2. LIST Response
>(snip)
>       \Noselect
>          It is not possible to use this name as a selectable mailbox.
However, your server returns wrong \NoSelect instead of correct \Noselect.

I guess that the wrong \NoSelect is caused by next bad string of \NoSelect in next section of RFC 3501(seen in Example of the next section only).
> 6.3.9. LSUB Command
>(snip)
>    Example:    C: A002 LSUB "#news." "comp.mail.*"
>                S: * LSUB () "." #news.comp.mail.mime
>                S: * LSUB () "." #news.comp.mail.misc
>                S: A002 OK LSUB completed
>                C: A003 LSUB "#news." "comp.%"
>                S: * LSUB (\NoSelect) "." #news.comp.mail
>                S: A003 OK LSUB completed

Your IMAP server looks to still have "bug of incorrect \NoSelect instead of correct \Noselect" in addition to already known/resolved "bug of incorrect \NoInferiors instead of correct \Noinferiors".
Because Tb ignores incorrect \NoSelect, I think it can explain phenomenon you saw.

Following is a web page found by Google search for "uw-imap \NoSelect".
> http://forums.mozillazine.org/viewtopic.php?f=31&t=289876
In this forum thread, Bug 291973 at B.M.O was referred.
> Bug 291973 - TB ignores folders with "NoSelect" and "HasChildren"
Bug 291973 was opened on 2005-04-26, and was changed to RESOLVED/EXPIRED on 2005-10-13.
Why can your server still have such old bug?
Why is the program so picky about the case?  Why is no case-insensitive matching used?
In RFC 3501 is says:

        (1) Except as noted otherwise, all alphabetic characters
        are case-insensitive.  The use of upper or lower case
        characters to define token strings is for editorial clarity
        only.  Implementations MUST accept these strings in a
        case-insensitive fashion.

This is said about the server implementation, but shouldn't it be true for the clients as well?

My server is running UW imap-2004c.  It is not practical to change this.  I can patch
the source if required, but I would like to point out that this server has been running
for many years with earlier versions of Seamonkey, and Dave is having the same problems
with another IMAP server (dovecot).
I think it is just wrong to be so picky about the case of the replies (NoSelect instead of Noselect), and that the standard is intending to take those as equivalent.
I have patched the source of UW IMAPD to return the flags the way you like them, but it has no influence on the occurrence of this bug (verified in log that it now returns Noselect etc).
The possibility to create a new folder still disappears after clicking around in the tree.
(In reply to Dave Ewart from comment #21)
> After uploading the debug log and screenshots earlier today, I saw the
> notification that Thunderbird 7.0 was released.  This bug seems not to
> happen with Thunderbird 7.0, which is excellent.  I assume that the
> corresponding version of SeaMonkey may now also work: Rob, can you confirm?

I have tested it on Linux for now, and the bug does not occur there.
I have to do further testing on Windows.  Also, Seamonkey 2.4 has other new bugs,
so I'm not sure we can roll it out just now.
(In reply to Rob Janssen from comment #24)
> I have patched the source of UW IMAPD to return the flags the way you like
> them, but it has no influence on the occurrence of this bug (verified in log
> that it now returns Noselect etc).
> The possibility to create a new folder still disappears after clicking
> around in the tree.

Thanks for testing with patch to clarify phenomenon.

Following is seen in Dave's IMAP log attached to comment #17.
> apollo.ceu.ox.ac.uk:A:SendData: 3 list "" "Mail/Stuff"
> apollo.ceu.ox.ac.uk:A:CreateNewLineFromSocket: * LIST (\Noselect \HasChildren) "/" "Mail/Stuff"
> apollo.ceu.ox.ac.uk:A:SendData: 6 list "" "Mail/Foo/Bar5"
> apollo.ceu.ox.ac.uk:A:CreateNewLineFromSocket: * LIST (\NoInferiors \UnMarked) "/" "Mail/Foo/Bar5"
Dovecot doesn't look to have "\NoSelect" issue.

By your test with patch, it's found that \NoInferiors(==no \Noinferiors for Tb) and \NoSelect(==no \Noselect for Tb) is irrelevant to problem, and it's foud that \Noinferiors and \Noselect is also irrelevant to problem. 
And, Dave's observation with Dovecot looks applicable to your case(UW-IMAP).
> In summary:
> Thunderbird 3.1: OK.
> Thunderbird 5: (Didn't test)
> Thunderbird 6: BUggy as described above.
> Thunderbird 7: OK.

According to comment #3 by David :Bienvenu, Tb's behavior seems next;
  dual_use_folders=true   \Noinferiors/\Noselect response is used,
                          \NoInferiors/\NoSelect is ignored.
  dual_use_folders=false  \Noinferiors/\Noselect response may be used,
                          \NoInferiors/\NoSelect is irrelevant as ignored.
As both you and Dave sets mail.server.serverX.dual_use_folders=false, it seems regression in dual_use_folders=false on Tb 6 over Tb 3 or 5, and is resolved by Tb 7.

Can you check Tb 6's behaviour in your environment(\NoInferiors/\NoSelect, or \NoInferiors/\Noselect, so Tb probably ignores both or one of two) with mail.server.serverX.dual_use_folders=true?
(Server Settings/Advanced, "Server supports folders that contain sub-folders and messages" is checked. Restart of Tb may be needed.)
Is not-lowest folder shown in Italic/grayed-out? (If \Noselect, probably Italic/grayed-out.)
How about folder creation menu? (If \Noinferiors, subfolder creation is probably prohibited.)

Can you check with latest trunk nightly build(thunderbird-9.0a1, seamonkey-2.6a1)?

[Off-Topic]
(In reply to Rob Janssen from comment #23)
> I think it is just wrong to be so picky about the case of the replies
> (NoSelect instead of Noselect), ....snip

I never simply said "INVALID because of server side problem". As seen in Bug 301714 Comment #5 and #7, UW-IMAP and Dovecot has code for torelance with Tb's Bug 301714 and it fortunately works very well on *nix server. I merely wanted to know why old/known problem still alives in real world and why bugs at B.M.O with IMAP log of "\NoInferiors" are opened relatively frequently. A version of software at server looks used far longer than I thought.
Bug 317597 was found for a problem around \NoInferiors/\NoSelect by UW-IMAP.
> Bug 317597 uwimap IMAP Server - noselect folders not honored in folder list
In that bug, "No folder attribute such as \Noselect in LSUB response from server" looks relevant to problem of that bug, and "unticking show subscribed folders only" looks workaround of that bug.
If LSUB response affect on "hide create folder menu or not", that setting may be relevant to this bug.
Can next be a workaround of this bug in SeaMonkey/2.3 or Thunderbird 6?
  Uncheck : "Show subscribed folders only"
(keep Unchecked: "Server supports folders that contain sub-folders and messages")
(In reply to WADA from comment #26)
Still testing with Seamonkey 2.3.3
With dual_use_folders=true the behaviour w.r.t. making new subfolders in the folder that can contain folders is correct.
I.e. it remains possible to create folders there also after navigating.

However, the "new subfolder" menu item is also present on folders that can contain only messages (incorrect), and it also is no longer possible to delete a folder with messages because the program attempts to create a Trash/ folder and move the folder there.  This is not possible because there already exists a Trash folder (with messages).

So, working with dual_use_folders=true is not feasible.

Extract from logging while attempting to create a subfolder test under SubFolder1
(where this should not be possible)

3036[4b6a640]: 4b61800:mail.uw:A:SendData: 3 select "Mail/ContainsFolders/SubFolder1"
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=12 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * 0 EXISTS
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=12 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * 0 RECENT
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=51 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 1317199004] UID validity status
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=37 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * OK [UIDNEXT 1] Predicted next UID
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=52 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=85 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=36 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:A:CreateNewLineFromSocket: 3 OK [READ-WRITE] SELECT completed
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:SendData: 4 IDLE
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=20 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: + Waiting for DONE
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:SendData: DONE
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=21 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: 4 OK IDLE completed
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:ProcessCurrentURL: entering
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:ProcessCurrentURL:imap://h%2Emulder@mail.uw:143/create%3E/ContainsFolders/SubFolder1/test:  = currentUrl
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:SendData: 5 create "Mail/ContainsFolders/SubFolder1/test"
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=108 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: 5 NO CREATE failed: Can't create mailbox node /home/h.mulder/Mail/ContainsFolders/SubFolder1/: File exists
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:SendData: 6 list "" "Mail/ContainsFolders/SubFolder1"
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=69 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: * LIST (\Noinferiors \Unmarked) "/" Mail/ContainsFolders/SubFolder1
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=21 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: 6 OK LIST completed
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:SendData: 7 IDLE
3036[4b6a640]: ReadNextLine [stream=4b22ac8 nb=20 needmore=0]
3036[4b6a640]: 4b61800:mail.uw:S-Mail/ContainsFolders/SubFolder1:CreateNewLineFromSocket: + Waiting for DONE
3000[41c7a80]: 4698800:mail.uw:S-INBOX:SendData: DONE

It shows the LIST that returns \Noinferiors is only done after the create of the subfolder was attempted.  Is that correct?
(In reply to Rob Janssen from comment #28)
> It shows the LIST that returns \Noinferiors is only done after the create of
> the subfolder was attempted.  Is that correct?

Thanks for additional testing.
Because you tested with your patch, your UW-IMAP server now returns \Noinferior to LIST as Mozilla expects(probably doesn't return to LSUB though). How about \Noselect in LIST and LSUB for mid level folder like Mail/ContainsFolders?
It may be phenomenon in Bug 317597 when folder attribute such as \Noselect in LSUB response is not returned from server.
Can you check Mozilla's behavior with next?
(i) dual_use_folders=true
(ii) Server returns \Noinferior/\Noselect to LIST as Mozilla expects,
     but not to LSUB (Your UW-IMAP with your patch probably behaves like this) 
(iii) Uncheck : "Show subscribed folders only"

Even when server doesn't support "folder can contain both subfolders and mails", if server returns \Noinferior/\Noselect to LIST&LSUB appropriately as Mozilla expects, Mozilla can behave correctly with dual_use_folders=true, although "create folder/ by user" is needed to create "folder contains subfoldes only" and Bug 301714 happens.
For example, if server returns "\Noselect, with no \Noinferiors" for mid level folder in both LIST and LSUB response, the mid level folder is shown in Italic/grayed-out, and create subfolder is enabled. If \Noinferiors is returned in both LIST and LSUB, create subfolder is disabled. 
(A) (iii) is a workaround of "no \Noinferior/\Noselect in LSUB response".
(B) (i), dual_use_folders=false, is a workaround of next;
    Server who doesn't support "folder contains both subfolder and mails"
    doesn't return \Noinferior/\Noselect appropriately as Mozilla expects",
    including \NoInferior/\NoSelect case.
Above test request is for whether workaround of (A) works or not in your environment.
This bug's problem seems that workaround of (B) doesn't work in Tb 6 but works in Tb 3/b 7.

> So, working with dual_use_folders=true is not feasible.

It's merely a test to see Mozilla's behavior when dual_use_folders=true, in order to know difference of Mozilla's behavior between dual_use_folders=true and dual_use_folders=false in your environment.
Please keep dual_use_folders=false in daily use or ordinal testing.
Confirming, based on evidences such as attached logs, screen shots.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here is the log as made with the patched UW IMAP that shows that LSUB does not return those \Noselect and \Noinferiors flags.
(this was with dual_use_folders=true)

Removing the "only show subscribed folders" is not such a good idea with UW IMAP as it will show the entire home directory of the user as mailfolders.
Other than that, there is no real change in what happens with the mail folders under test.

I will now fetch the newest UW IMAP and see if I can get it compiled and installed on the server and use instead of the 2004c version which is a bit old.
(I need to re-engineer one or two patches that we made in the past)
However, I must re-iterate that it has always provided us good service, both with Seamonkey and with Squirrelmail.
I gave tested with the newest UW IMAP (2007f released july this year) and it turns out that:

- there is no difference in what LSUB returns
- this version still returns the flags you call "wrong" (\NoSelect, \NoInferiors)
- there is no difference in the behaviour of Seamonkey 2.3.3 when using this IMAP server instead of version 2004c that we used a long time
(In reply to Rob Janssen from comment #32)
> I gave tested with the newest UW IMAP (2007f released july this year) and it
> turns out that:
> - there is no difference in what LSUB returns

UW-IMAP looks never changed this behaviour on LSUB.

> - this version still returns the flags you call "wrong" (\NoSelect,
> \NoInferiors)

IIRC, "\Noinferiors by UW-IMAP" was optional and was not enabled by default.

> - there is no difference in the behaviour of Seamonkey 2.3.3 when using this
> IMAP server instead of version 2004c that we used a long time

Thanks for checking with last UW-IMAP.
As for Mozilla's behaviour of dual_use_folders=true with UW-IMAP, already known problems with UW-IMAP seems to still occur. Such problems with UW-IMAP looks successfully bypassed by dual_use_folders=false for long time.

For Mozilla's current behaviour dual_use_folders=false on Mail/ContainsFolders/SubFolder1 ;
  Account : Is folder creation menu available?
  Mail : Italic/grayed-out. Is subfolder creation menu available?
  ContainsFolders : Italic/grayed-out. Subfolder creation menu is not available.
                    (this bug's problem)
  SubFolder1 : Lowest level, created without trailing "/", 
               so folder contains mail only, no subfolder creation menu.
If "folder or subfolder creation menu" is available at account level or Menu folder level, I think folder creation by next is possible. Is it right?
  account level     : create Mail/ContainsFolders/SubFolderX
  Mail folder level : create subfolder of ContainsFolders/SubFolderX

This bug doesn't seem to occur in next Tb 7. Does this bug occur in SeaMonkey 2.4.1 which was released some days ago?
You are asking questions that were already answered in my first report of the problem!

It *is* possible to create a folder at the top of the account, just not under a folder that contains folders.
The menu that pops up when creating a folder at the account level allows the user to select a place to create the folder, but once this bug has occurred it is not possible to select the folder ContainsFolders as a location ("choose this for the parent" is greyed out in the subfolder selection menu when this location is selected).

About the whole \\NoInferiors vs \\Noinferiors mess:
If it is really true that those are different to Seamonkey/Thunderbird, I think it is a bug that should be fixed.  I have yet to see any evidence that there is such difference, but if you insist that there is please change it to a case-insensitive match as intended by the IMAP standard, because you really cannot insist that IMAP servers follow your ideas of how those flags should look.

I checked the source of UW IMAPd 2007f and there is no indication whatsoever that the case of those flags can be changed by an option, and they all are in the source as mixed case:

      if (attributes & LATT_NOINFERIORS) strcat (tmp," \\NoInferiors");
      if (attributes & LATT_NOSELECT) strcat (tmp," \\NoSelect");
      if (attributes & LATT_MARKED) strcat (tmp," \\Marked");
      if (attributes & LATT_UNMARKED) strcat (tmp," \\UnMarked");
      if (attributes & LATT_HASCHILDREN) strcat (tmp," \\HasChildren");
      if (attributes & LATT_HASNOCHILDREN) strcat (tmp," \\HasNoChildren");
I have upgraded our clients to Seamonkey 2.4.1 and rolled back the UW IMAPd to 2004c (because it caused a new problem).
All seems to be well for now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: