201197 - not all imap folders are displayed

Status: RESOLVED DUPLICATE of bug 197262

(MailNews Core :: Networking: IMAP, defect)

Description

[Colin Blake]

Mozilla V1.3, running IMAP via an OpenVMS V7.3-1 box with IP V5.3.

Mozilla/5.0 (X11; U; OpenVMS AlphaPC_264DP_500_MHz; en-US; rv:1.3) Gecko/20030313

Microsoft Outlook Express (via IMAP) shows all of the OpenVMS MAIL folders,
using the same path into the same OpenVMS IMAP server.

But when I try to display the folders from Mozilla using IMAP access, the
Mozilla display ends in the middle of the P* folders.

From the OpenVMS MAIL utility, I see:

...
PCSI
PDF
PERL
PHOENIX
POR
PORT
PORTING
PORT_CLASS
POSIX
POSTMASTER
...

From Mozilla, I see:
  
...
PCSI
PDF
PERL
PHOENIX
POR

The POR folder is very close to the two-hundredth folder.

Comment 1

[grylchan]

possibly dupe of bug 138759, bug 200989

Comment 2

[Colin Blake]

Those bugs seem to be when there is a deep folder structure. That is not the
case here. I believe the user (not me) has over 200 folders at the level 0 or 1
level.

Comment 3

[Colin Blake]

I found the problem. A great many files are opened when processing IMAP mail
folders. It would appear that you need 2*N files where N is the number of
folders, and that's just for the IMAP mail. You also need about 100 open files
just to crank up Mozilla and all its shareables. 

FILLM >= 2 * N + 100

Comment 4

[Colin Blake]

I've sent a note to our writer to add something about this to our release notes.

Closing.

Comment 5

[Colin Blake]

Reopening. There should be some kind of message displayed if a mail folder can't
be accessed because the process has reached its open file quota. The open() or
opendir() or whatever which fails should trigger and error/warning.

Changing OS to all since I presume the error detecting code is missing for all
platforms.

Comment 6

[David :Bienvenu]

I assume there's a limit to the number of files that can be open at one time,
not the number of files that can be opened and closed, right? We should be
closing all the files opened, except for the open folders. Also, we only
open/create one file per folder, unless your folders are configured for offline use.

Are these newly discovered folders? I.e., has mozilla seen these folders before?
We shouldn't be opening any files for folders we've seen before, if panacea.dat
is doing its job, and someone hasn't screwed things up.

Comment 7

[Colin Blake]

> I assume there's a limit to the number of files that can be open at one time,
> not the number of files that can be opened and closed, right? 

Correct.

> We should be closing all the files opened, except for the open folders. Also,
> we only open/create one file per folder, unless your folders are configured
> for offline use.

These IMAP folders were not modified in any way. Whatever the default is.

> Are these newly discovered folders? I.e., has mozilla seen these folders
> before? We shouldn't be opening any files for folders we've seen before,
> if panacea.dat is doing its job, and someone hasn't screwed things up.

When I first configured the IMAP mail account, yes, they were newly discovered.
But even when I exited Mozilla and restarted I still had the same problem.

I'll try to get a list of which files are open.

Comment 8

[Colin Blake]

The MSF file is help open for each folder.

Comment 9

[Colin Blake]

The MSF file is held open for each folder.

Comment 10

[David :Bienvenu]

so that's just one file per folder, and then one file for each directory, but
you said you had a flat hierarchy. On windows, we only seem to have the .msf
files open for the folders we've actually used. I'm not sure why openVMS would
be different.

Comment 11

[Colin Blake]

You're right. Once all the folders have been discovered then the files are NOT
held open.

But I believe there is a problem in the discovery phase, where if an open
(network or file) fails, that's its not getting reported. This causes the
discovery phase to silently abort or hang (I've seen both), and then when you
restart Mozilla the discovery phase runs again (and again it silently aborts or
hangs).

Comment 12

[David :Bienvenu]

dup of bug 197262 - this should be fixed in a 1.5 trunk build from today on.

*** This bug has been marked as a duplicate of 197262 ***