299133 - New POP account not created correctly, unusable

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[Tracy Walker [:tracy]]

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.

Comment 1

[Tracy Walker [:tracy]]

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

Comment 2

[Tracy Walker [:tracy]]

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

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[Doug Turner (:dougt)]

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

Comment 5

[David :Bienvenu]

I can pull and build and investigate...

Comment 6

[Tracy Walker [:tracy]]

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

Comment 7

[Doug Turner (:dougt)]

Tracy -- thanks for the data.

I will chat with bienvenu and mscott to figure out what we can do.

Comment 8

[David :Bienvenu]

Attachment: mailnews part of proposed fix

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.

Comment 9

[David :Bienvenu]

Attachment: nsIFileSpec changes

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

Comment 10

[David :Bienvenu]

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 11

[Daniel Veditz [:dveditz]]

Comment on attachment 187704 [details] [diff] [review]
nsIFileSpec changes

sr=dveditz
a=dveditz when given r=

Comment 12

[Daniel Veditz [:dveditz]]

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 13

[Doug Turner (:dougt)]

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

fine.

Comment 14

[Doug Turner (:dougt)]

Comment on attachment 187704 [details] [diff] [review]
nsIFileSpec changes

I wrote it; xpcom needs only one review.

Comment 15

[Doug Turner (:dougt)]

landed on trunk and branch.

Comment 16

[Daniel Veditz [:dveditz]]

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

Comment 17

[Doug Turner (:dougt)]

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.

Comment 18

[Karsten Düsterloh]

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?

Comment 19

[Doug Turner (:dougt)]

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.

Comment 20

[Doug Turner (:dougt)]

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

Comment 21

[Doug Turner (:dougt)]

Attachment: 700 permission set for directories

Comment 22

[Doug Turner (:dougt)]

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

Comment 23

[Karsten Düsterloh]

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

Comment 24

[Daniel Veditz [:dveditz]]

Comment on attachment 188208 [details] [diff] [review]
700 permission set for directories

r/sr/a=dveditz
Please land this everywhere

Comment 25

[Doug Turner (:dougt)]

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.

Comment 26

[Karsten Düsterloh]

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.

Comment 27

[Jay Patel [:jay]]

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

Comment 28

[Benjamin Smedberg]

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.

Comment 29

[Benjamin Smedberg]

This broke enigmail, BTW.

Comment 30

[Doug Turner (:dougt)]

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.

Comment 31

[Darin Fisher]

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.

Comment 32

[Doug Turner (:dougt)]

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

Comment 33

[Benjamin Smedberg]

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.

Comment 34

[Doug Turner (:dougt)]

API changes were backed out on the branches.

Trunk fix coming soon.

Comment 35

[Daniel Veditz [:dveditz]]

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.

Comment 36

[Frank Wein [:mcsmurf]]

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.

Comment 37

[Martin Creutziger [:MMx]]

Shouldn't this be FIXED with Thunderbird 1.0.6?

Comment 38

[Scott MacGregor]

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