Closed Bug 308311 Opened 19 years ago Closed 19 years ago

Local Folders - Changing directory not possible

Categories

(Thunderbird :: Account Manager, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gw, Assigned: neil)

References

Details

(Keywords: fixed1.8)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Thunderbird version 1.5 Beta 1 (20050908)

Duplication:

Tried to check if this bug is reported already for Thunderbird 1.5 Beta 1, but
did not find anything. So I will post my report here

Description:

In Thunderbird 1.5 Beta 1, under "Tools" / "Account Settings", the local
directories for the mail storage can be changed. For the individual accounts
under "Server Settings" it is possible to change the local directory, by
clicking the "Browse" button. After selecting the desired directory, the value
is changed in the field to the left of the button.

However, for "Local Folders" this change is not possible. The "Browse" button
permits browsing to the desired location of the mails, but when clicking the
folder, the value is not changed in the field to the left of the "Browse" button.

I tried by going into the Config Editor, and changed the directory value there.
The default entry for "mail.server.server1.directory" is "C:\Documents and
Settings\Erbes\Application Data\Thunderbird\Profiles\irloc4mw.default\Mail\Local
Folders", which corresponds to the default setting for "Local Folders" under
"Tools" / "Account Settings". In the ConfigEditor I changed this value to
another location, but this change was not shown in the field next to the
"Browse" button under "Tools" / "Account Settings". Closing the program and
opening it again, showed that the value for "mail.server.server1.directory" in
the ConfigEditor had been set back to the default setting again. So it appears
to be impossible to change the directory location for "Local Folders".

This bug makes Thunderbird unusable when the user wants to store the emails in
another location or system-independent partition, which is a critical feature.
Therefore I classify the bug as critical.

Reproducible: Always

Steps to Reproduce:
1. Thunderbird 1.5 Beta 1
2. Go to "Tools" / "Account Settings"
3. In the left box go to "Local Folders"
4. In the right box go to the "Local Directory"-section and the "Browse" button
5. Click and select any given directory location
6. The change is not accepted, and the value in the field remains unchanged.

Actual Results:  
The desired changes are not accepted by the program

Expected Results:  
Accept a new directory location
do any messages appear on the js console when you try this?
Did you try restarting the program after setting that preference?
See bug 2654 -- if you're seeing the same thing, please mark this bug as a dupe 
of that one.
(In reply to comment #2)
> Did you try restarting the program after setting that preference?
> See bug 2654 -- if you're seeing the same thing, please mark this bug as a dupe 
> of that one.

1. Restarting does not help. Settings still unchanged
2. Does NOT appear to be same as bug#2654
(In reply to comment #1)
> do any messages appear on the js console when you try this?

No messages appear on the js-console.
I am also facing the same problem.  I had to reinstall Thunderbird and I am 
able to map all mail accounts to their respective folders except Local 
Folders.  It allows me to browse to the right folder location but does not 
chnage the value.  This is a big problem for me as it have a lot of email 
stored in the local folders and I have no way of retrieving it.  I have tried 
all options of checking for errors, restarting etc. etc.

Some of my thoughts are: The "Local Folders" folder has sub-folder under it 
and I suspect Thunderbird has an issue with assigning a folder which has sub-
folders under it.  Is this correcT?
Confirming with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050916
Thunderbird/1.4 ID:2005091605

Do get an error in the JS console:

Error: gServer is not defined
Source File: chrome://messenger/content/amUtils.js
Line: 67
Severity: critical → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Confirming the same error in Javascript console as the one mentioned by Magnus 
Melin:

Error: gServer is not defined
Source File: chrome://messenger/content/amUtils.js
Line: 67

Using Mozilla Thurderbird version 1.5 beta 1 ID:20050908

works on trunk, broken on branch. I'll look into why tomorrow.
Did we get a resolution for this issue? I have so much email in that folder 
that I need to retrieve. Please please help me.
(In reply to comment #8)
> works on trunk, broken on branch. I'll look into why tomorrow.

Can someone tell me what is going on?  I am having problems with about 3 GB of 
email in that folder.
Don't know what changed, but this is now WORKSFORME using
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051012
Thunderbird/1.4.1 ID:2005101205

I can now change the dir. Of course the messages/folders aren't moved over when
it's changed but I guess they never did.
The exact bug described persists under Windows XP 
Thunderbird versions 1.5 and  1.6a1 (20051014), the latest 
nightly build. 
Yeah, ignore my previous comment. Still see this in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051026 Thunderbird/1.5 ID:2005102604
Experiencing the same thing here with version 1.5 Beta 2 (20051006)
Thunderbird/1.4.1 still unable to successfully select a folder to store messages.
This is "Critical!" 
Seeing this with TB 1.5 RC1 (20051025, winxp). Looks like a regression of a 0.8 bug: https://bugzilla.mozilla.org/show_bug.cgi?id=259230
(In reply to comment #15)
> Seeing this with TB 1.5 RC1 (20051025, winxp). Looks like a regression of a 0.8
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=259230
>

I am also seeing this with the RC1 version of Thunderbird (and noticed in Beta 2 also)

However, I did figure out the manual edit necessary to work around the problem.  The process for that is that in addition to editing "mail.server.server1.directory" to point to your required directory, you also need to edit line after it in prefs.js, the "mail.server.server1.directory-rel" setting.  Delete everything after the [ProfD] and then replace it with your desired directory path preceded by 7 "../" pairs. :-).  I used

"mail.server.server4.directory", "D:\\larryp\\Mail\\mail.tor.alias.com"
"mail.server.server4.directory-rel", "[ProfD]../../../../../../../D:/larryp/Mail/mail.tor.alias.com"

seems like a very inefficient way to get to the right place, but it did actually work.
(In reply to comment #16)
Well it did not work for me, but there is one thing I don't understand in your example: why "server4" and not "server1" ?

I think this bug is the outcome of bug #275107 (yes, 2005-02-01!!!). :(
Previously gServer was defined in am-serverwithnoidentities.js, which however doesn't exist anymore on the mozilla 1.8 branch (Neil deleted it).
Hum, bad QA from my side... :( I've felt sad for a moment, but then I made a patch. ;)

Adding regression keyword (oops, I don't have the privileges), expect a patch in a few seconds...
Attached patch possible fix (obsolete) — Splinter Review
Scott, what do you think?
Attachment #202162 - Flags: review?(mscott)
(In reply to comment #17)
> (In reply to comment #16)
> Well it did not work for me, but there is one thing I don't understand in your
> example: why "server4" and not "server1" ?

Good question, the answer seems to be history.  My prefs file is very, very old as I have been using flavours of Netscape, Mozilla and now Thunderbird for a long time and each new installation just copies and upgrades that.  At the moment I do not have a server1 in my file, server 2 is "Local Folders" and server3 is my "news" server.  I did not think the "number" mattered, so I just left it alone.
(In reply to comment #17)
> (In reply to comment #16)
> Well it did not work for me, but there is one thing I don't understand in your
> example: why "server4" and not "server1" ?

Ooops, just realized I did not respond to the first part of the question ... I tried this workaround, editing both "directory" and "directory-rel" on two different Thunderbird 1.5 RC1 installations in Windows XP SP2, one of which had 4 email accounts set up (I edited all of them) and they all worked. If the edit left the path in "directory-rel" even slightly wrong, then when TB started up the account would have no folders under it, but once the path was accurate (enough ../ pairs to walk back up to "root", then the drive name and a path to the directory containing "Inbox") everything worked again.  I have no I idea why the same workaround would do it for you also.
(In reply to comment #21)
> I have no I idea why the same workaround would do it for you also.
> 
Well it does work now: I failed to notice that I should use "\" on first line instead of "/" as in second line. Sorry for that.
But I made it work by an other way:
- I installed back version 1.0.7
- I deleted default Local Folder (maybe not necessary)
- I selected my own Local Folder
- I installed again 1.5 RC1
and that'it !
It's still not possible to change directory with RC1, but at least it does not revert to default one.

Comment on attachment 202162 [details] [diff] [review]
possible fix

this is a good start bisi.

In general, a g before the variable name implies that it is a global variable which it isn't in this case.

An ideal fix would be to rename your variable to say "server" and then change the folks that use that variable inside the method.
Attachment #202162 - Flags: review?(mscott) → review-
*** Bug 315652 has been marked as a duplicate of this bug. ***
Attached patch don't complicate... (obsolete) — Splinter Review
You should be a teacher in an elementary school (seriously)! ;]

Enough joking. The previous patch was totally wrong (oops). Here's just a function, which already existed in am-serverwithnotidentities.js (gServer is now defined). Is it ok gScott or do I get more homework? :)
Attachment #202162 - Attachment is obsolete: true
Attachment #202580 - Flags: review?(mscott)
Comment on attachment 202580 [details] [diff] [review]
don't complicate...

The thing that makes me nervous about this patch is that amUtils.js is loaded by several files and not just the am-serverwithnoidentities.xul

onPreInit could be defined in any of those files as well. And I don't think a utility JS file should be implementing an onPreInit method which is usually reserved for the actual account panel objects themselves.
Attached patch Almost backoutSplinter Review
The .js file is not quite identical to the original .js file,
hopefully this will not regress the warning fix.
Attachment #203321 - Flags: review?(mscott)
Comment on attachment 202580 [details] [diff] [review]
don't complicate...

Sure, clearing my review request. Neil has a better patch, which kind of reintroduces the deleted file.
Attachment #202580 - Attachment is obsolete: true
Attachment #202580 - Flags: review?(mscott)
Comment on attachment 203321 [details] [diff] [review]
Almost backout

Neil, feel free to check this into the 1.8 branch as well. 

a=me for that.

This change would have zero effect on Firefox. I suspect you'll want this for the suite branch build.

And if we have to respin Thunderbird 1.5 at some point from the branch, I'd want this in there as well.

Thanks for putting together the right fix for this.
Attachment #203321 - Flags: review?(mscott) → review+
Fix checked in to the trunk.
Assignee: mscott → neil.parkwaycc.co.uk
Fix checked in to the 1.8 branch.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
*** Bug 317698 has been marked as a duplicate of this bug. ***
Attachment #204607 - Flags: superreview?(bienvenu)
Attachment #204607 - Flags: superreview?(bienvenu) → superreview+
(In reply to comment #33)
> Created an attachment (id=204607) [edit]
> make this fix work for thunderbird too
> 

The Product: already lists Thunderbird, so I hope so, or should Product: be changed to Core?
*** Bug 201798 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.