545243 - Need a pref to define ImapMail Parent/Default directory location

Status: RESOLVED INVALID

(Thunderbird :: Preferences, enhancement)

Description

[Charles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 3.0.1 final

This would be so I could force IMAP offline stores to go anywhere I wanted - ie, the Local Settings folder instead of the roaming part of the user profile.

Reproducible: Always

Comment 1

[Mark Banner (:standard8)]

Go into Account Settings, select Server Settings for the account you wish to change, then at the bottom of that page you'll find "Local Directory" where you can set what you want.

I believe that's what you want.

Comment 2

[Charles]

Yes, but that must be done on a per account basis, *after* the account is created, and can only be done through the GUI.

I want a way to specify this in the user.js file, that will apply to *all* accounts - or at least to all *new* accounts when created.

Meaning:

1. I add a line to the user.js file that gets copied to each users brand shiny new profile, before any accounts are created,

2. This line instructs Thunderbird to set the 'Local Directory' to one underneath this predefined path.

Setting back to UNCONFIRMED.

Comment 3

[David :Bienvenu]

mail.root.imap-rel controls this. But it is a relative directory, so you need to set it relative to the profile directory. For an example of how to do this, you can try changing the directory of one of your existing imap accounts to point outside the profile dir, and look at that server's directory-rel pref using the config editor.

Comment 4

[Charles]

Hmmm... thanks David, but...

I just entered 'mail.root' in about:config, and am I missing something, or isn't mail.root.imap more what I'm looking for? This is currently defined precisely as:

C:\Documents and Settings\MyUser\Application Data\Thunderbird\Profiles\blahblah.default\ImapMail

That is what I want to change. So, the question is, can I add a line to user.js like:

%UserProfile%\Local Settings\Thunderbird\ImapMail

and have it work as I'm hoping?

I'll experiment tomorrow and post my results if no one can answer authoritatively...

Comment 5

[David :Bienvenu]

Only the -rel prefs are used at this point. The non -rel prefs are obsolete and should have been removed.

Comment 6

[Charles]

Ahh... ok, thats kind of ugly, but:

[ProfD]../../../../Local Settings/Thunderbird/ImapMail should do it then...

But, what if I wanted to store this on another drive entirely... lets see...

Ouch, that's even uglier, but doable:

[ProfD]../../../../../../../E:/blah

Would it do any good to make this enhancement request to bring back a non-relative setting for this?

Comment 7

[David :Bienvenu]

(In reply to comment #6)

> 
> [ProfD]../../../../../../../E:/blah
> 
> Would it do any good to make this enhancement request to bring back a
> non-relative setting for this?

No, we use relative paths everywhere so that normal users can move profiles easily.

Comment 8

[Charles]

Oh, right, I remember the days of the salted profile being hard-coded in the paths of config files, so that makes perfect sense then.

Thanks David... and before closing this bug, can you confirm that adding:

user_pref("mail.root.imap-rel", "[ProfD]../../../../Local Settings/Thunderbird/ImapMail");

to user.js will do the trick? I'll test tomorrow to confirm.

But if that is true, then I guess we can close this bug...

Thanks again!

Comment 9

[David :Bienvenu]

(In reply to comment #8)
> 
> Thanks David... and before closing this bug, can you confirm that adding:
> 
> user_pref("mail.root.imap-rel", "[ProfD]../../../../Local
> Settings/Thunderbird/ImapMail");

I looked at the code and it should work but you'll need to try it to be sure :-)

Comment 10

[Charles]

Ok, although you said that the old mail.root.imap was obsolete and should have been removed, apparently it is still being used. In fact, *both* mail.root.imap and mail.root.imap-rel must be changed before the offline store for new accounts changes to the new location. Changing either one separately results in the original/default [ProfD]ImapMail setting being used.

(Oh - and what are mail.root.none and mail.root.none-rel for?)

Steps to reproduce:

I made the following changes manually to the uer.js file and restarted TB after each change.

I tried setting mail.root.imap-rel pref first, created a new account, and it still created the new account offline store in the old/original/default location in %AppData%.

I then set mail.root.imap to the same as what I changed -rel too, created a new account, and this time it did create the offline store in the new location in Local Settings.

Just to be sure I then changed the -rel pref back to the default, created a new account, and it reverted back to the default location.

So again, apparently *both* need to be changed to achieve the desired result.

I'm on Windows XP Pro sp3 (up to date), with TB 3.0.1 release, and used my clean/testing v3 profile.

Should I open another bug about this?

Comment 11

[David :Bienvenu]

The way I remember the code is supposed to work is if the rel pref exists, the non-rel pref is ignored, but it's ancient core code. It may fall back if the pref points to a non-existent directory; I really don't know.

The none pref is for the local folders, iirc.

Comment 12

[Charles]

(In reply to comment #11)
> The way I remember the code is supposed to work is if the rel pref exists, the
> non-rel pref is ignored, but it's ancient core code.

Ok, so something is apparently broken if that's the way its supposed to work, because thats not how it worked when I tested it.

> It may fall back if the pref points to a non-existent directory; I really
> don't know.

Well, the directory existed (I created it before testing)... <shrug>

> The none pref is for the local folders, iirc.

Oh, right (duh, it is set to [ProfD]Mail - I must be blind)... thanks... :)

Comment 13

[Charles]

(In reply to comment #11)
> The way I remember the code is supposed to work is if the rel pref exists, the
> non-rel pref is ignored, but it's ancient core code. It may fall back if the
> pref points to a non-existent directory; I really don't know.

Ok, opened bug 545681 to track this...