Closed Bug 254668 Opened 20 years ago Closed 16 years ago

Remove hardcoded paths from prefs.js

Categories

(Thunderbird :: Preferences, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: Waldo, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

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.
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.
QA Contact: general
Assignee: mscott → nobody
Component: General → Preferences
QA Contact: general → preferences
Timeless replies "Yes." :) Nominating wanted-thunderbird3?
Flags: wanted-thunderbird3?
Version: unspecified → Trunk
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?
Flags: wanted-thunderbird3? → wanted-thunderbird3-
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.
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?
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 :).
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Depends on: 888371
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: