68370 - Account setup fails if incoming servername > 31 characters

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Backend, defect)

Description

[meiering]

While setting up an email account using the account wizard, if the incoming
server name is greater than 32 characters, the account will be setup, but will
not function correctly. In particular, there is no "inbox" "drafts",
"templates", etc listed in under the account.

To reproduce setup an email account with an incoming servername of 32 or more
characters. 

e.g. If I use the server 
meiering.deskmail.washington.edu - it fails, but
meierin.deskmail.washington.edu  - is okay.

Furthermore, the prefs written to prefs.js indicate that there is no location
set for the inbox, etc.

Here's a listing of my mail settings in prefs

user_pref("mail.account.account1.identities", "id2");
user_pref("mail.account.account1.server", "server1");
user_pref("mail.account.account2.server", "server2");
user_pref("mail.account.account3.identities", "id5");
user_pref("mail.account.account3.server", "server3");
user_pref("mail.accountmanager.accounts", "account2,account1,account3");
user_pref("mail.accountmanager.defaultaccount", "account2");
user_pref("mail.accountmanager.localfoldersserver", "server2");
user_pref("mail.identity.id2.draft_folder", "mailbox://[e-mail]/Drafts");
user_pref("mail.identity.id2.fcc_folder", "mailbox://[e-mail]/Sent");
user_pref("mail.identity.id2.fullName", "Foo Bar");
user_pref("mail.identity.id2.organization", "");
user_pref("mail.identity.id2.reply_to", "");
user_pref("mail.identity.id2.stationery_folder",
"mailbox://[e-mail]/Templates");
user_pref("mail.identity.id2.useremail", "[e-mail]");
user_pref("mail.identity.id2.valid", true);
user_pref("mail.identity.id5.fullName", "Foo Barred");
user_pref("mail.identity.id5.useremail", "[e-mail]");
user_pref("mail.identity.id5.valid", true);
user_pref("mail.root.none",
"AAAAAAGuAAIAAQNPUzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC13DUtQkQAAAAA2CgETWFpbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYK7ap0U0AAAAAAAAAAP////8AAAARAAAAAAAAAAAAAAAAAAAADHpreWp4YmpsLnNsdAABABQAANgoAADYJwAA2CYAANBqAAAWuwACADxPUzk6RG9jdW1lbnRzOk1vemlsbGE6VXNlcnM1MDpEZWZhdWx0IFVzZXI6emt5anhiamwuc2x0Ok1haWwACQCoAKhhZnBtAAAAAAADABgAOQBZAHUAlQCeD1NFTFUgTGFiIEJsZGcgQgAAAAAAAAAAAAAAAAAAAAAAA1lvIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADT1M5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACG1laWVyaW5nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAA==");
user_pref("mail.root.pop3",
"AAAAAAGuAAIAAQNPUzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC13DUtQkQAAAAA2CgETWFpbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYK7ap0U0AAAAAAAAAAP////8AAAARAAAAAAAAAAAAAAAAAAAADHpreWp4YmpsLnNsdAABABQAANgoAADYJwAA2CYAANBqAAAWuwACADxPUzk6RG9jdW1lbnRzOk1vemlsbGE6VXNlcnM1MDpEZWZhdWx0IFVzZXI6emt5anhiamwuc2x0Ok1haWwACQCoAKhhZnBtAAAAAAADABgAOQBZAHUAlQCeD1NFTFUgTGFiIEJsZGcgQgAAAAAAAAAAAAAAAAAAAAAAA1lvIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADT1M5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACG1laWVyaW5nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAA==");
user_pref("mail.server.server1.directory",
"AAAAAAG6AAIAAQNPUzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC13DUtQkQAAAAA2CsOZnJlZC5maGNyYy5vcmcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYabap0h0AAAAAAAAAAP////8AAAARAAAAAAAAAAAAAAAAAAAABE1haWwAAQAYAADYKwAA2CgAANgnAADYJgAA0GoAABa7AAIAS09TOTpEb2N1bWVudHM6TW96aWxsYTpVc2VyczUwOkRlZmF1bHQgVXNlcjp6a3lqeGJqbC5zbHQ6TWFpbDpmcmVkLmZoY3JjLm9yZwAACQCoAKhhZnBtAAAAAAADABgAOQBZAHUAlQCeD1NFTFUgTGFiIEJsZGcgQgAAAAAAAAAAAAAAAAAAAAAAA1lvIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADT1M5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACG1laWVyaW5nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAA==");
user_pref("mail.server.server1.hostname", "foo.fhcrc.org");
user_pref("mail.server.server1.name", "Foo");
user_pref("mail.server.server1.type", "pop3");
user_pref("mail.server.server1.userName", "foobar");
user_pref("mail.server.server2.directory",
"AAAAAAG4AAIAAQNPUzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC13DUtQkQAAAAA2CsNTG9jYWwgRm9sZGVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYY7ap0YAAAAAAAAAAAP////8AAAARAAAAAAAAAAAAAAAAAAAABE1haWwAAQAYAADYKwAA2CgAANgnAADYJgAA0GoAABa7AAIASk9TOTpEb2N1bWVudHM6TW96aWxsYTpVc2VyczUwOkRlZmF1bHQgVXNlcjp6a3lqeGJqbC5zbHQ6TWFpbDpMb2NhbCBGb2xkZXJzAAkAqACoYWZwbQAAAAAAAwAYADkAWQB1AJUAng9TRUxVIExhYiBCbGRnIEIAAAAAAAAAAAAAAAAAAAAAAANZbyEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA09TOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhtZWllcmluZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//AAA=");
user_pref("mail.server.server2.hostname", "Local Folders");
user_pref("mail.server.server2.name", "Local Folders");
user_pref("mail.server.server2.type", "none");
user_pref("mail.server.server2.userName", "nobody");
user_pref("mail.server.server3.hostname", "meiering.deskmail.washington.edu");
user_pref("mail.server.server3.name", "[e-mail]");
user_pref("mail.server.server3.type", "pop3");
user_pref("mail.server.server3.userName", "foobarred");
user_pref("mail.smtp.defaultserver", "smtp1");
user_pref("mail.smtpserver.smtp1.auth_method", 0);
user_pref("mail.smtpserver.smtp1.hostname", "foo.fhcrc.org");
user_pref("mail.smtpserver.smtp1.try_ssl", 1);
user_pref("mail.smtpserver.smtp1.username", "");
user_pref("mail.smtpservers", "smtp1");

missing the following pref
user_pref("mail.server.server3.directory", "");

Comment 1

[Keyser Sose]

Reporter do you have a test account we can use?

Comment 2

[meiering]

Sorry, don't have a real test account. However, to reproduce the problem try
making two new accounts with the following as incoming mail servers 

1. 1234567.deskmail.washington.edu
2. 12345678.deskmail.washington.edu 

#1 will setup a proper account and #2 will not... at least in my hands. 

When you are finished you will notice that in the Mail/News window that account
#1 has an arrow widget next to it and #2 doesn't. Hence, #1 will have an inbox,
etc and #2 won't 

hope that helps

Comment 3

[Bradley Hart]

I'm seeing this also, Mac OS 8.6 build 2001022013. Could this be related to Mac
OS's limit on the number of characters in file/folder names? Marking NEW.

Comment 4

[Ninoschka Baca]

I have also reproduced this on the Mac but not Win or Linux.

Comment 5

[Steve Dagley]

Yes, you're being bit by the Classic Mac OS limit 31 character filename limit.  
Look at the 4.x mail source to see how this should be handled.  If you can't find 
it, ping me for help.

Comment 6

[Bradley Hart]

I checked out the NS 4.x source off lxr.mozilla.org, and could not find how 
this was handled. I did stumble across, however, several references to 
truncating filenames to make them work on Mac OS. COuld this have been how this 
was handled? 

I'll try to look some more...

Comment 7

[Steve Dagley]

I didn't think any of the 4.x mail/news source made it into the Mozilla Classic 
tree (ask someone who was involved how aptly named the Normandy landing was for 
the attempted merging of mail/news back into the Mozilla Classic tree).  I _know_ 
the fix I put into 4.74 is not in the Moz Classic source.  The file you want to 
look in is ns/cmd/macfe/utility/xp_file_mac.cp.  The diff for the fix I made for 
editing IMAP filters is (assuming you're inside the Netscape firewall):

<http://warp.netscape.com/webtools/bonsai/cvsview2.cgi?diff_mode=context&
whitespace_mode=show&root=/m/src&subdir=ns/cmd/macfe/utility&command=
DIFF_FRAMESET&root=/m/src&file=xp_file_mac.cp&rev1=1.31.14.5.2.21&rev2=
1.31.14.5.2.22>

Note that this was on a branch and if you're just browsing with blame or lxr 
you'll get the tip which does not have that change.

Comment 8

[Bradley Hart]

I found the file at 
http://lxr.mozilla.org/classic/source/cmd/macfe/utility/xp_file_mac.cp

According to that, file names are indeed truncated to 31 characters or less 
with the function:

if(specName.Length() + extension.Length() > 31)
149             {
150                 specName.Length() = 31 - extension.Length();
151             }
152             specName += extension;
153         } else {
154             XP_ASSERT(0);
155         }
156     }


I hope this helps.

Comment 9

[racham]

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

Comment 10

[saari (gone)]

nsbeta1- as per ADT

Comment 11

[Steve Dagley]

I'm gonna chime in here with my $.02 and say that this was a big 4.x issue for
either educational or commercial users so I don't think it's deserving of
nsbeta1-.  Nor is it only a problem on Mac OS 9 as our current Mac OS X builds
are restricted to 31 character file names as well (old summary referring to 32
characters was wrong).  And the fix should be simple (and sample code from 4.x
was given as a reference almost a year ago)

Comment 12

[Michael Buckland]

Discussed at Mail News bug meeting with Engineering, QA Mktng and PjM.  Decided
to minus this bug.

Comment 13

[Sheela Ravindran]

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

Comment 14

[Greg K.]

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

Comment 15

[Greg K.]

So this worked in 4.x? Adding 4xp keyword.

Comment 16

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 17

[Simon Paquet [:sipaq]]

happens on MacOS X too. Mac Classic is dead. Moving over to OS X.

Comment 18

[Stefan [:stefanh]]

I'm resolving this as wfm. I set up an account on SeaMonkey 1.1.16 with an incoming server name of 37 chars and I don't see any of the issues in comment #0.