Absolute paths in prefs.js, i.e. "mail.server.serverX.directory" property should be removed completely

NEW
Unassigned

Status

defect
6 years ago
6 years ago

People

(Reporter: Ulf.Zibis, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

17 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130620135945

Steps to reproduce:

Moved profile from Windows to Linux.


Actual results:

In prefs.js I still see windows paths:
user_pref("mail.server.server1.directory", "C:\\Dokumente und Einstellungen\\xxx\\Anwendungsdaten\\Thunderbird\\...");
Result: ThunderPlunger addons folder monitoring at start of TB doesn't work.


Expected results:

The paths should be updated after running on different OS or better, those properties should be removed as the seem superfluous.
Blocks: 252099, 254668
Component: Untriaged → Preferences
See Also: → 196119
Summary: ng profile to LinuxWindows paths in prefs.js not updated after movi → Windows paths in prefs.js should be updated after moving profile to Linux OR "mail.server.serverX.directory" property should be removed completely
Profile files are not independent from the underlying operating system. Files shoudn't be copied to other systems.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
I didn't know about the rules to mark a bug as "wontfix" and I just has been tell about that.

Sorry.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(In reply to Ulf Zibis from comment #0)
> User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101
> Firefox/22.0 (Beta/Release)
> Build ID: 20130620135945
> 
> Steps to reproduce:
> 
> Moved profile from Windows to Linux.
> 
> 
> Actual results:
> 
> In prefs.js I still see windows paths:
> user_pref("mail.server.server1.directory", "C:\\Dokumente und
> Einstellungen\\xxx\\Anwendungsdaten\\Thunderbird\\...");
> Result: ThunderPlunger addons folder monitoring at start of TB doesn't work.

Note that this preference doesn't actually matter, and is kept around for historical reasons. The preference we actually use is directory-rel, which is relative to the profile directory and does not need \-versus-/ translation between different operating systems.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → WONTFIX
See Also: → 929406
(In reply to Javi Rueda from comment #1)
> Profile files are not independent from the underlying operating system.
> Files shoudn't be copied to other systems.

Hm, then please correct this article:
http://kb.mozillazine.org/Sharing_a_profile_between_Windows_and_Linux
Ulf, is the profile actually not working when you switch OS? Is it just the cosmetic problem that you see wrong path in the prefs.js?
The profile is actually working when I switch OS, except bug 929406 for now.
For add-ons, that rely on that path, the problem is more than cosmetic.
In general, I would prefer profile relative paths in prefs.js.
There are profile relative paths (directory-rel). If any addon is using the absolute path instead of the relative one, it whould be filed against the addon. Maybe we should just remove the absolute paths. I wonder which TB version used them in the past and if we still want to support downgrades to it.
CVS archeology would tell, but i don't think there ever was a thunderbird release without the rel paths. I tracked it back to at least 2004, but it probably existed before that some time. Yes, we could probably get away with removing support for the absolute paths ;)
I reopen this bug to make the remove ever happen.
Developers could be mislead to develop in-reliable Addons.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Summary: Windows paths in prefs.js should be updated after moving profile to Linux OR "mail.server.serverX.directory" property should be removed completely → Absolute paths in prefs.js, i.e. "mail.server.serverX.directory" property should be removed completely
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 883645 could block.
Depends on: 883645
OS: Linux → All
Hardware: x86_64 → All
> Magnus Melin 2013-12-20 00:05:14 PST
> Status: UNCONFIRMED → NEW

mail.server.server#.directory-rel is always used by Tb already.
mail.server.server#.directory is for backword compatibility of prefs.js, isn't it?
Or there is already no need of backward compatibility by mail.server.server#.directory?
Or "confusions by users, add-on developers, Tb developers" is far critical and important problem than "loss of a backward compatibility in prefs.js with old/non-supported Tb releases" nowadays?
FYI.
"Removal of mail.server.server#.directory" currently means;
  Loss of easiest/simples circumvention of "delete .directory-rel and restart Tb"
  in following case.
    Profile copy to different directory depth,
    and Mail directory at outside of Tb's profile directory.

  In this case, .directory-rel points different place(different depth) after profile copy,
  because .directory-rel is dead copy of it in original profile.
  .directory keeps absolute path when original profile was used.
  Therefore, "delete .directort-rel" can be a easiest/simplest method to use mail directory
  which is located at outside of profile directory after "profile copy to different
  directory depth".
In this case it's backwards compatibility with versions probably even predating thunderbird itself, so I don't think anyone would mind if it's not supported.
(In reply to Magnus Melin from comment #13)
I see. I agree with you on that "downward compatibility of prefs.js on .directory entry with Mozilla family who didn't support .directory-rel, who is perhaps not officially released Thunderbird" is not needed any more for recent/future Tb releases.

How about SeaMonkey and "loss of easiest/simplest circumvention method of a problem, which is produced by .directory-rel only use, which I stated in comment #12"?
Another question to Magnus. 

What is cause of "confusions or complaints by users, add-on developers, or Tb developers on absolute path in .directory, even though .directory was kept for backword copatibility and .directory-rel was/is used by recent Tb always"?
Culplit is "existence of absolute path in .directory of prefs.js for backward compatibility" himself?
I can't think so.
It's usually "User see absolute path in .directory of prefs.js, so user opens bug at b.M.O where is never support forum/help center, where is for developers to resolve bugs, and he complaints about 'Tb still holds absolute path in prefs.js'".
If it's done by add-on developer, it's merely fault of add-on developer.
If it was done by Tb developers, I can say nothing...
(In reply to WADA from comment #14)
> How about SeaMonkey and "loss of easiest/simplest circumvention method of a
> problem, which is produced by .directory-rel only use, which I stated in
> comment #12"?

SeaMonkey is a younger product than Thunderbird, they did a migration a few years back so I don't think that is a problem.

Non-standard storage locations is not a good idea if you don't know what you're doing. And if you know what you're doing you can easily copy over just the mails - which is what matters to people. IMHO way easier to figure out than finding an obscure pref for a numbered account and deleting that.

I have no answer for comment 15.
(In reply to Magnus Melin from comment #16)
> Non-standard storage locations is not a good idea if you don't know what you're doing. 
> And if you know what you're doing you can easily copy over just the mails (snip)
I see. I believe who intentionally uses non standard mail directory location, even though developers never recommend it, can look into prefs.js by himself and he can see and change "Local Directory:" setting by himself without opening bug at B.M.O, even if .directory-rel points different directory level by his profile copy to different depth.

It looks that there is no problem in removing mail.server.server#.directory and mail.root.none/pop3/imap/nntp.
You need to log in before you can comment on or make changes to this bug.