seen on windows Tbird branch build 2005-06-29-06-aviary1.0.1 and Mac build 2005-06-29-05-aviary1.0.1 -launch with a clean(new) profile -Create a POP account (it doesn't matter if you choose global inbox or not) tested results: The account isn't getting created correctly. The account appears in the folder pane, but is missing all the usual mail boxes and folders. Clicking Get Mail does nothing. The settings for the account all look good. expected results: The POP account is created correctly with all the usual boxes and folders and is usable. note: IMAP account creation works fine. Migrated POP accounts (not global inbox) work too. I'll have to do more investigating on Global inbox import and migration.

I smoketested 1.0.5 Tbird two days ago and account creation for POP was fine.

also seeing on linux Tbird 1.0.5 2005-06-29-07-aviary1.0.1

Whatever it is, it looks like my fault: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_1_20050124_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fcvsroot I'm betting it's bug 212123. again.

bienvenu, do you have any other ideas why pop account would fail?

I can pull and build and investigate...

narrowed the regression window: 2005-06-27-07-aviary1.0.1 - POP account creation works 2005-06-28-06-aviary1.0.1 - POP account creation broken change in bug 212123 is the only thing in that window

Tracy -- thanks for the data. I will chat with bienvenu and mscott to figure out what we can do.

Doug has a patch that allows the nsIFileSpec consumer to indicate that they want to create a unique directory, and this mailnews patch uses that call.

this is Doug's xpcom/obsolete part. I tested with both patches and pop3 server directories are created correctly...

Comment on attachment 187704 [details] [diff] [review] nsIFileSpec changes my one nit would be to either comment MakeUnique to say that the converse of inCreateFile is to create a directory, or change the name and sense of the variable to inCreateAsDir (and flip the value but not the sense of the default, so that we still default to creating files).

Comment on attachment 187704 [details] [diff] [review] nsIFileSpec changes sr=dveditz a=dveditz when given r=

Comment on attachment 187703 [details] [diff] [review] mailnews part of proposed fix please use the cvs diff '-p' option to help reviewers out a bit a=dveditz for trunk and branches.

Comment on attachment 187703 [details] [diff] [review] mailnews part of proposed fix fine.

Comment on attachment 187704 [details] [diff] [review] nsIFileSpec changes I wrote it; xpcom needs only one review.

landed on trunk and branch.

This was not checked into the mozilla 1.7 branch so this regression will afflict 1.7.9

Checking in xpcom/obsolete/nsFileSpec.cpp; /cvsroot/mozilla/xpcom/obsolete/nsFileSpec.cpp,v <-- nsFileSpec.cpp new revision: 1.5.32.9; previous revision: 1.5.32.8 done Checking in xpcom/obsolete/nsFileSpec.h; /cvsroot/mozilla/xpcom/obsolete/nsFileSpec.h,v <-- nsFileSpec.h new revision: 1.6.2.6; previous revision: 1.6.2.5 done Checking in xpcom/obsolete/nsFileSpecImpl.cpp; /cvsroot/mozilla/xpcom/obsolete/nsFileSpecImpl.cpp,v <-- nsFileSpecImpl.cpp new revision: 1.5.4.1; previous revision: 1.5 done Checking in xpcom/obsolete/nsIFileSpec.idl; /cvsroot/mozilla/xpcom/obsolete/nsIFileSpec.idl,v <-- nsIFileSpec.idl new revision: 1.5.2.1; previous revision: 1.5 done Checking in mailnews/base/util/nsMsgIncomingServer.cpp; /cvsroot/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp,v <-- nsMsgIncomingServer.cpp new revision: 1.201.2.1; previous revision: 1.201 done Checked into 1.7 branch.

At least today's (2005-07-04) and reportedly yesterday's Linux Seamonkey trunk builds can't create subfolders to "Local Folders" etc. in fresh profiles, because "Local Folders" has directory permissions 600. Maybe this is a regression of this bug?

reopening based on last comment. the directory is indeed being created with the 600 permission: http://lxr.mozilla.org/seamonkey/source/xpcom/obsolete/nsFileSpec.cpp#919 Probably should be with execute bit set.

*** Bug 299647 has been marked as a duplicate of this bug. ***

i check the last patch into the trunk to see if it would fix the problem. We can get tracking quickly tomorrow and then apply the patch to the branches when we know it does fix the problem. Checking in nsFileSpec.cpp; /cvsroot/mozilla/xpcom/obsolete/nsFileSpec.cpp,v <-- nsFileSpec.cpp new revision: 1.12; previous revision: 1.11 done

btw: I filed bug 299647 for the issue but forgot linking from here. Sorry.

Comment on attachment 188208 [details] [diff] [review] 700 permission set for directories r/sr/a=dveditz Please land this everywhere

AVIARY_1_0_1_20050124_BRANCH: Checking in nsFileSpec.cpp; /cvsroot/mozilla/xpcom/obsolete/nsFileSpec.cpp,v <-- nsFileSpec.cpp new revision: 1.5.36.1.2.9; previous revision: 1.5.36.1.2.8 done MOZILLA_1_7_BRANCH: Checking in nsFileSpec.cpp; /cvsroot/mozilla/xpcom/obsolete/nsFileSpec.cpp,v <-- nsFileSpec.cpp new revision: 1.5.32.10; previous revision: 1.5.32.9 done Checked in at or around 22:42 pst july 4. Tommorrow builds should have fix.

Created a fresh profile with the 2005-07-05 seamonkey-1.0a.en-US.linux-i686-gtk1.tar.gz and had no directory permission problems anymore.

v.fixed on Aviary with Thunderbird version 1.0.5 (20050709)

This really sucks: we changed the nsFileSpec API in such a way that mailnews extensions which were using it are now broken, without revving the extension version. A much more reasonable change would have been to add a new method on nsFileSpec, with much less chance to break existing linkage. I would like to nominate that we revert the filespec change and use a new API instead on the branch.

This broke enigmail, BTW.

breaking extensions because they used nsFileSpec doesn't break my heart. If I am going to spend another minuted on anything nsFileSpec related, it will be to remove it from the tree.

It's not a stable branch if we change interfaces :-/ Unfortunately, nsIFileSpec is still widely used by mailnews, so it isn't enough to make the argument that it is deprecated. We should have removed nsIFileSpec from mailnews ages ago, but we didn't, and we can't change the fact that the 1.0.x tbird series depends on it.

we changed both the nsFileSpec and the nsIFileSpec. Which is breaking the plugin/extension?

From reports on #developers, the nsFileSpec change is what's breaking enigmail, popping up linkage errors when upgrading from tb 1.0.2 to the candidate builds.

API changes were backed out on the branches. Trunk fix coming soon.

Why is this reopened? Does anyone have trouble creating a POP account on any of the branches? AFAIK the trunk never had a backout of 212123 or this one. This one was backed out of the branches, but so was bug 212123 which caused it -- so still not a problem.

We're doomed or something ;). It seems we shipped the wrong build, i tried today: Downloaded Thunderbird 1.0.5 release, installed Enigmail 0.92.0, on next start of Thunderbird i get the same error message as in Bug 300477 again.

Shouldn't this be FIXED with Thunderbird 1.0.6?

I'm going to reclose this because it was fixed a long time ago.