Closed Bug 244217 Opened 20 years ago Closed 18 years ago

Initial Mail retrieval from POP account fails(mac only)


(SeaMonkey :: MailNews: Message Display, defect)

Not set


(Not tracked)



(Reporter: trix, Unassigned)



(Whiteboard: fixed-aviary1.0)


(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Unable to retrieve mail after creating new POP email account.

Reproducible: Always
Steps to Reproduce:
1. Remove Profiles directory: HD:Users:[Uname]:Library:Mozilla
2. Bypass initial reg setup.
3. Setup Email (POP)Account.
4. Attempt to download messages.
Actual Results:  
No response

Expected Results:  
Should allow you to download messages.

Closing/reopening app corrects this problem and able to download messages. 
Works in Moz1.6 & Nscp7.1

Problem does occur on moz 1.7(20040518)
confirm and accepting.

this affects trunk and 1.7

this is where we fail:

 if(NS_SUCCEEDED(rv) && rootFolder)
    PRUint32 numFolders;
-->rv = rootFolder->GetFoldersWithFlag(MSG_FOLDER_FLAG_INBOX, 1, &numFolders,
  nsCOMPtr<nsIMsgLocalMailFolder> localInbox = do_QueryInterface(inbox, &rv);

we fail to find the inbox folder.

I'll continue to debug later tonight.
Ever confirmed: true
target for 1.7 final.
Target Milestone: --- → mozilla1.7final
I just noticed something interesting.

when I first start up, in my folder pane, my Inbox folder doesn't have the right
"special" icon, denoting it's an inbox.

I'll screen shot.
something is calling ClearFlag() on the inbox, and we are losing the
MSG_INBOX_FOLDER_FLAG, which explains the UI and the fact that
GetFoldersWithFlag() is failing.
there was some code that attempted to set or clear the junk flag that might be
responsible...I reviewed a fix recently - though why this would be mac only I
don't know...
actually, it doesn't look like ClearFlags() is the problem.  (it looks like we
are just clearing the has new mail flag)

we do appear to call SetFlag/SetFlags() on the inbox with the right flags, but
when debugging the inbox has flags of 5.  (instead of 1024 + 5).

maybe we have more than one inbox nsMsgDBFolder in memory?  (do you remember
weirdness like that before that confused the datasource)?
debugging with david reveals what's going on.

the problem is here:

because Inbox.msf doesn't exist, we fail silently.

#0  nsPersistentFileDescriptor::operator=(nsFileSpec const&) (this=0xbfff89f0,
inSpec=@0x11b7020c) at nsFileSpec.cpp:1230
#1  0x031994d8 in
nsPersistentFileDescriptor::nsPersistentFileDescriptor(nsFileSpec const&)
(this=0xbfff89f0, inSpec=@0x11b7020c) at nsFileSpec.cpp:1201
#2  0x03199470 in
nsPersistentFileDescriptor::nsPersistentFileDescriptor(nsFileSpec const&)
(this=0xbfff89f0, inSpec=@0x11b7020c) at nsFileSpec.cpp:1200
#3  0x0319e32c in nsFileSpecImpl::GetPersistentDescriptorString(char**)
(this=0x11b70200, aPersistentDescriptorString=0xbfff8b14) at nsFileSpecImpl.cpp:175
#4  0x103d88dc in nsMsgDBFolder::GetFolderCacheElemFromFileSpec(nsIFileSpec*,
nsIMsgFolderCacheElement**) (this=0x11b706a0, fileSpec=0x11b70200,
cacheElement=0xbfff8bb0) at nsMsgDBFolder.cpp:465
#5  0x103d8a74 in nsMsgDBFolder::ReadDBFolderInfo(int) (this=0x11b706a0,
force=0) at nsMsgDBFolder.cpp:491
#6  0x103db1cc in nsMsgDBFolder::GetFlags(unsigned*) (this=0x11b706a0,
_retval=0xbfff8cf0) at nsMsgDBFolder.cpp:1040
#7  0x23ce4154 in nsMsgLocalMailFolder::AddSubfolder(nsAutoString*,
nsIMsgFolder**) (this=0x11b6c300, name=0xbfff8f00, child=0xbfff8fa0) at
#8  0x23ce38c8 in nsMsgLocalMailFolder::CreateSubFolders(nsFileSpec&)
(this=0x11b6c300, path=@0xbfff90b0) at nsLocalMailFolder.cpp:233
#9  0x23ce5488 in nsMsgLocalMailFolder::GetSubFolders(nsIEnumerator**)
(this=0x11b6c300, result=0xbfff91c0) at nsLocalMailFolder.cpp:529
#10 0x1e3c71ac in nsMsgFolderDataSource::createFolderChildNode(nsIMsgFolder*,
nsIRDFNode**) (this=0x119284d0, folder=0x11b6c328, target=0xbfff9460) at
#11 0x1e3c346c in nsMsgFolderDataSource::createFolderNode(nsIMsgFolder*,
nsIRDFResource*, nsIRDFNode**) (this=0x119284d0, folder=0x11b6c328,
property=0x112ad60, target=0xbfff9460) at nsMsgFolderDataSource.cpp:1051
#12 0x1e3c0124 in nsMsgFolderDataSource::GetTarget(nsIRDFResource*,
nsIRDFResource*, int, nsIRDFNode**) (this=0x119284d0, source=0x11b6c300,
property=0x112ad60, tv=1, target=0xbfff9460) at nsMsgFolderDataSource.cpp:380
#13 0x04fd0d80 in CompositeDataSourceImpl::GetTarget(nsIRDFResource*,
nsIRDFResource*, int, nsIRDFNode**) (this=0x10ce2350, aSource=0x11b6c300,
aProperty=0x112ad60, aTruthValue=1, aResult=0xbfff9460) at
#14 0x12d848ec in
nsRDFConInstanceTestNode::FilterInstantiations(InstantiationSet&, void*) const
(this=0x11930650, aInstantiations=@0xbfff9520, aClosure=0xbfff9800) at
#15 0x12d8d674 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x11930650, aInstantiations=@0xbfff95c0, aClosure=0xbfff9800) at
#16 0x12d8d788 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x11930250, aInstantiations=@0xbfff9660, aClosure=0xbfff9800) at
#17 0x12d8d788 in TestNode::Propagate(InstantiationSet const&, void*)
(this=0x1192fef0, aInstantiations=@0xbfff9780, aClosure=0xbfff9800) at
#18 0x12daa1b0 in nsXULTemplateBuilder::Propagate(nsIRDFResource*,
nsIRDFResource*, nsIRDFNode*, nsClusterKeySet&) (this=0x2a72c00,
aSource=0xf9a12c0, aProperty=0x112ad60, aTarget=0x11b6c300,
aNewKeys=@0xbfff9800) at nsXULTemplateBuilder.cpp:422
#19 0x12daa524 in nsXULTemplateBuilder::OnAssert(nsIRDFDataSource*,
nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (this=0x2a72c00,
aDataSource=0x10ce2350, aSource=0xf9a12c0, aProperty=0x112ad60,
aTarget=0x11b6c300) at nsXULTemplateBuilder.cpp:493
#20 0x04fd3050 in CompositeDataSourceImpl::OnAssert(nsIRDFDataSource*,
nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (this=0x10ce2350,
aDataSource=0x11928060, aSource=0xf9a12c0, aProperty=0x112ad60,
aTarget=0x11b6c300) at nsCompositeDataSource.cpp:1462
#21 0x1e3bd1bc in nsMsgRDFDataSource::assertEnumFunc(nsISupports*, void*)
(aElement=0x10ce2354, aData=0xbfff99e0) at nsMsgRDFDataSource.cpp:404
#22 0x01bb957c in nsSupportsArray::EnumerateForwards(int (*)(nsISupports*,
void*), void*) (this=0x119280a0, aFunc=0x1e3bd150
<nsMsgRDFDataSource::assertEnumFunc(nsISupports*, void*)>, aData=0xbfff99e0) at
#23 0x1e3bd0f4 in nsMsgRDFDataSource::NotifyObservers(nsIRDFResource*,
nsIRDFResource*, nsIRDFNode*, int, int) (this=0x11928060, subject=0xf9a12c0,
property=0x112ad60, object=0x11b6c300, assert=1, change=0) at
#24 0x1e3cfb60 in
(this=0x11928060, aServer=0x11b6c1d0) at nsMsgAccountManagerDS.cpp:1276
#25 0x1e3b53dc in nsMsgAccountManager::NotifyServerLoaded(nsIMsgIncomingServer*)
(this=0xf99f650, server=0x11b6c1d0) at nsMsgAccountManager.cpp:1770
#26 0x1e3b9998 in nsMsgAccount::SetIncomingServer(nsIMsgIncomingServer*)
(this=0x11b6e0c0, aIncomingServer=0x11b6c1d0) at nsMsgAccount.cpp:191

-43 == File or directory not found; incomplete pathname
I'm beginning to think the bug is that mac os x acts differently than win32 / linux.


mac will silently fail if the file does not exist.

I think the thing to do is check for fnfErr, and if we get that, create the file.

and I think I'll add an assert to this code so that problems like this will be
easier to catch later.
Attached patch patch (obsolete) — Splinter Review
a fix, suggested by david.
Attachment #149159 - Flags: superreview+
Comment on attachment 149162 [details] [diff] [review]
better patch, sorry about the confusion

back to my original suggestion :-)
Attachment #149162 - Flags: superreview?(bienvenu) → superreview+
fixed on both trunk and branch.

I think we should assert in sPersistentFileDescriptor::operator= if we that code
silently fails on MacOS X.

I'll log a new bug on that.
Closed: 20 years ago
Resolution: --- → FIXED
This change is causing the contents of newsgroups and IMAP mail folders to be
redownloaded when opened. (on FreeBSD)
It seems to be truncating the msf files to zero bytes.
> This change is causing the contents of newsgroups and IMAP mail folders to be
> redownloaded when opened. (on FreeBSD)
> It seems to be truncating the msf files to zero bytes.

yikes, I think I see that too on win32.

something is really wrong.  I'll back out my change.
or, I'll fix my change to check if the .msf file exists before calling Touch()., thanks for catching the regression so quick.
Attachment #149231 - Flags: superreview+
ok, I've landed my supplimental fix.
both patches fixed on the aviary 1.0 branch
Whiteboard: fixed-aviary1.0
*** Bug 244575 has been marked as a duplicate of this bug. ***
*** Bug 244615 has been marked as a duplicate of this bug. ***
Keywords: fixed1.7
*** Bug 244919 has been marked as a duplicate of this bug. ***
*** Bug 245146 has been marked as a duplicate of this bug. ***
Used latest Mozilla 1.7 06-15 nightly build on Mac:
Yes. This bug was fixed for initial mail retrieval from mail client itself.
But, if tried to initial mail from the browser (e.g Without setup mail yet,
tried to initial mail during "Send Link" or "Send Page" from the browser. Then I
am able to reproduce this problem described above....also I saw the
INBOX displays on the last from the folder pane.
Resolution: FIXED → ---
Reopening and removing "fixed1.7" for this bug based on above verification.
Keywords: fixed1.7
QA Contact: karenlhuang
now that david has a fix for bug #252843, this might be fixed.
Depends on: 252843
vrfy'd fixed on aviary1.0 with tbird 2004112202-0.9 on mac os x 10.3.6.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Resetting to Fixed per comment 26-27.
Closed: 20 years ago18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.