Closed Bug 720285 Opened 12 years ago Closed 12 years ago

Script failure trying to change Server Local Directory in Thunderbird mail accounts.

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Version:
9 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 218439

People

(Reporter: ralphcyn, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

On Windows 7, tried to change the Local Directory under Tools > Account Settings > Server Settings.  I'm trying to change a secondary account to have the same Local Directory as the primary account.


Actual results:

Received an error message that says:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: chrome://messenger/content/amUtils.js:70

There are two buttons:

Continue Stop script

Regardless of which response I give, the end result is that I cannot change the Local Directory.  This looks similar to Bug 308311, but that was fixed in 2005.  I don't always get the Script Failed message, but it still doesn't work.


Expected results:

The Local Directory should have changed to the folder of my choice.  This worked on my XP system (still does, at the same Thunderbird level).
But why do you need to have 2 accounts have the same Local Directory? I am not sure that is supported.
I have one Local Directory on XP that is pointed to by 4 different email addresses.  I want all mail to these IDs to come into the same Local Directory.  Three of the IDs are mine -- the 4th is my wife's.  I do a Get Mail for all 4 accounts at one time and mail for all 4 IDs comes in with one Get Mail.  I was able to do this on XP, but am being disallowed on Windows 7.  I don't want this mail to go to 4 different directories.  It's a management headache.
(In reply to Ralph R. Rayner from comment #2)
> I have one Local Directory on XP that is pointed to by 4 different email
> addresses.  I want all mail to these IDs to come into the same Local
> Directory.  Three of the IDs are mine -- the 4th is my wife's.  I do a Get
> Mail for all 4 accounts at one time and mail for all 4 IDs comes in with one
> Get Mail.  I was able to do this on XP, but am being disallowed on Windows
> 7.  I don't want this mail to go to 4 different directories.  It's a
> management headache.

You can do this simply by deferring the storage for 3 of the account's to the 4th account (or defer all of them to the global inbox). See account settings, server settings, advanced button for how to defer the storage of an account to an other account's inbox.
David, can it even work if 4 accounts point to the same physical folder and also use the same Inbox file concurrently? Isn't that prone to corruption? Or do you have proper transactions on the mbox files?
"Crash" of bug 218439 looks changed to "Script error".
Although user currently can select same directory at Server Settings of multiple accounts because Tb doesn't protect Tb from it since initial, "same local directory for multiple accounts" was not supported since initial of Moziila and is never supported, even if it works temporary and partially.
aceman, can you add "duplication check of local directory" in bug 224831?
I think I'd better do it in bug 218439. I'd rather not add new functionality in patch for bug 224831, it is already stalled enough :)
Depends on: 218439
(In reply to David :Bienvenu from comment #3)

> 
> You can do this simply by deferring the storage for 3 of the account's to
> the 4th account (or defer all of them to the global inbox). See account
> settings, server settings, advanced button for how to defer the storage of
> an account to an other account's inbox.

Thank you, David.  This workaround does the job.  And thank you everyone for your contributions to this thread.  When the other questions raised are resolved, this thread may be closed.

Ralph
(In reply to Ralph R. Rayner from comment #8)
> When the other questions raised are
> resolved, this thread may be closed.

Which ones are those? Has the unresponsive script error disappeared?
No, the problem with the failing script remains.  David gave me a workaround.  When the failing script issue is resolved, this thread may be closed from my viewpoint.  I am content to move ahead with the workaround.

Ralph
(In reply to :aceman from comment #4)
> David, can it even work if 4 accounts point to the same physical folder and
> also use the same Inbox file concurrently? Isn't that prone to corruption?
> Or do you have proper transactions on the mbox files?

If you do the deferring that I described above, then yes, because TB knows that you're doing it, and serializes requests to download mail from different servers into the same folder. This isn't a work around; it's the way we intend people to use the same Inbox for different pop3 servers.

An alternative is using the unified folder view where we present all Inboxes as one virtual folder but still have separate storage folders.

I suspect this bug has to do with the fact there's a syntax error in the js code that tries to prevent users from re-using server directories - see https://bugzilla.mozilla.org/show_bug.cgi?id=147711#c19
(In reply to Ralph R. Rayner from comment #10)
I think David gave you the only official supported configuration. That was no workaround. He is the expert TB developer on folders and datastorage.

If the script error is not seen in this official configuration then this report can be closed.

(In reply to David :Bienvenu from comment #11)
> I suspect this bug has to do with the fact there's a syntax error in the js
> code that tries to prevent users from re-using server directories - see
> https://bugzilla.mozilla.org/show_bug.cgi?id=147711#c19
Thanks for finding another dupe, I am already fixing this if you do not mind.
Any idea what to do with this bug?
The fix that prevents user getting into this unsupported scenario landed in bug 218439.
I think we fixed this, and that this bug is a dup.
oh, so mark this as a dup of the bug that you fixed that prevented the warning coming up.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.