254668 - Remove hardcoded paths from prefs.js

Status: RESOLVED INCOMPLETE

(Thunderbird :: Preferences, defect)

Description

[Jeff Walden [:Waldo]]

Per bug 211628 comment 26 I'm filing a bug (finally, I've been way too busy
recently) to get rid of the remaining hard-coded paths in Thunderbird that would
make it not work quite correctly from, say, a USB stick.  This bug probably
would complement (or be a dupe of) bug 252099 quite a bit, as I ran across these
paths while trying to share a Thunderbird installation between Windows and Linux.

I'm attaching a purged copy of my prefs.js file in a second.  I've removed
everything that can't possibly be connected to paths.  For what's left, I've
loosely moved it around so that what I perceive as most likely to be flawed is
near the top and what's almost definitely fine is near the bottom.  /Hopefully/
from this it'll be possible to determine what's right and what's wrong.

Comment 1

[Jeff Walden [:Waldo]]

Attachment: My prefs.js, cleaned of useless info and slightly reorganized

One caveat for the file: because Thunderbird has no good email backup setup in
place, my profile is rather crufty.  I think it's very roughly the same one as
when I first started using Thunderbird, which would have been around
Thunderbird 0.5.  It's gone through the wringer during that time. 
Consequently, there's a possibility it's too old to be useful.	If so, just
tell me and I'll do my best to figure out how to copy *only* my email into a
new installation with an otherwise clean profile.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

is this wanted?

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Timeless replies "Yes." :)

Nominating wanted-thunderbird3?

Comment 4

[Phil Ringnalda (:philor)]

It's certainly not wanted without some description of what the problem is that needs to be solved. Do the -rel variants not work? Do we want the non-rel variants removed for aesthetic reasons, and tough luck for anyone who uses a pre-1.7 (I think that's when the -rels landed) build? Does the last-attachment-directory pref not fail nicely enough, or would it be more satisfactory with a relative path?

Comment 5

[David :Bienvenu]

We don't use the non-rel variants, so Phil is right - what's left? I'd say this bug is fixed, unless we're writing out non-rel variants for new profiles.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

FWIW, I checked with a newly created profile on Mac, and after I set up a newsgroup server, in my prefs.js I still see mail.server.server1.directory vs its -rel variant.

IRC conversations reveal that the hardcoded paths are created but not used, so this bug should be about removing their creation?

Comment 7

[timeless]

yes definitely stop creating them.

fwiw, someone should file a bug about generating paths that embed absolute locations (drive letters or unc paths):
user_pref("mail.identity.id1.sig_file-rel", "[ProfD]../../../../../../../../d:/Thunderbird/signature.txt");

that should just be folded into an absolute path. otherwise if i change the location of my profile directory, the path breaks :).

Comment 8

[Phil Ringnalda (:philor)]

timeless: I think you might have misunderstood what we need - rather than a blanket assertion that we must stop creating them because you say so plus a digression, we were really looking for some explanation of *why* we should stop creating them. They exist to allow you to have a chance at using a profile with older builds, from before the other variants landed. If you don't use your profile with an older build, then they are created and left unread. I'm willing to believe that there might be a reason other than "we hates them, we do" to stop creating them, so I wouldn't call it wontfix just yet, but it's sure incomplete so far.