Closed Bug 247973 Opened 20 years ago Closed 9 years ago

Profiles should be stored under "Mozilla/Thunderbird" not "Thunderbird" (no vendor set)

Categories

(Thunderbird :: OS Integration, defect)

Product:
Thunderbird
Component:
OS Integration
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

(Whiteboard: [See bug 424641 for implementation issues])

Attachments

(1 obsolete file) 

Mozilla Thunderbird should follow Mozilla Firefox in the default location for
it's profiles.

Mozilla Firefox 0.9 puts its profiles in "%APPDATA%\Mozilla\Firefox" while
Mozilla Thunderbird puts its in "%APPDATA%\Thunderbird"

Mozilla Thunderbird should use "%APPDATA%\Mozilla\Thunderbird" to be consistent!
*** Bug 252927 has been marked as a duplicate of this bug. ***
*** Bug 259266 has been marked as a duplicate of this bug. ***
Shouldn't this be fixed before 1.0?

i think it's critical that we get consistency between the apps
*** Bug 258517 has been marked as a duplicate of this bug. ***
Merging multiple bugs describing the same problem into a single bug.

The default profile location should be moved to following locations before we
reach TB1.0. If this part is implemented after 1.0 we need an additional profile
migration. Now we have *beta* software were it is simplier to switch.

Linux: ~/.mozilla/Thunderbird
Windows: X:\Documents and Settings\%user%\Application Data\Mozilla\Thunderbird

Scott, could we land this perhaps for the next release?
Flags: blocking-aviary1.0?
OS: Windows XP → All
Hardware: PC → All
*** Bug 260765 has been marked as a duplicate of this bug. ***
Scott, did you want to WONTFIX this? It should either be blocking+ or wontfix.
Benjamin, I'm ok with the idea in principle of making new profiles show up in
the new correct location as long as we don't force migration to occur with
profiles that are in the current location. Otherwise we can't change the profile
location.
i.e. if we can do it such that the new profiles.ini file in the new location
just points back to the existing profile then let's do it.
Attached patch the patch if we choose to take it (obsolete) (deleted) — — Splinter Review 
this seems to do the right thing on windows with a single profile. Haven't
tested on Mac OS X yet nor with multiple profiles.
Applied patch and tested on windows with multiple profiles. I couldn't find any
regressions. Seems to work fine.
OK, I'll have an "import" patch coming up shortly.
Assignee: mscott → bsmedberg
Flags: blocking-aviary1.0? → blocking-aviary1.0+
removing the plus for now. I haven't decided that I want to do this yet. I'm
just proposing the patch and letting some of us test it out.
Flags: blocking-aviary1.0+
Wow!  Is this an argument for my BUG#266345, or what!

Anyhow, YES PLEASE, this should be done if at all possible.
*** Bug 267374 has been marked as a duplicate of this bug. ***
Why was the "blocking-aviary1.0" flag removed?
To get more information for moving the profile folder, I've searched for the
associated FF bug. It's movement from folder %appdata% to %appdata%\mozilla is
covered by bug 171561. 

Scott, does your patch also work for Linux and Mac OS X? No more work is to do?
If not, it sounds really simple.

For the import patch we shouldn't make the same failures like happened for
Firefox. The profile has to be fully imported.

We have following scenarios:

First installation of TB
------------------------
No profile exists. We don't need the import feature but just creating a fresh
folder within %appdata%\mozilla.

A profile already exists
------------------------
Within the folder %appdata%\Thunderbird more than one profile is listed. Here we
have to possibilities:

1. Relative profile location

Profiles whose laying under the above (old) default profile location should be
copied/moved to the new location. Cause mail data can uses a lot of disk space
we should ask the user to copy or move the profile data. 


2. Absolute profile location

Profiles whose laying outside the default profile location shouldn't be
copied/moved to %appdata%\mozilla\thunderbird. Instead only a new entry has to
be created inside profiles.ini which has a reference to the current profile
location. This was a situation which raised a lot of problems and irritates the
users because profile data was silently copied to a new location.

Scott, I set the asking for blocker flag again so that we don't forget this bug.
Flags: blocking-aviary1.0?
This doesn't need to block, we can do it after 1.0 if necessary. Existing
profiles aren't going to move, we're just going to put new profiles in the new
location and "import" the old profiles.ini.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
It would be consistant indeed to store data in %appdata%\thunderbird
Isn't this patch ready to land (it's after 1.0?)
Attachment #163078 - Flags: review?(mscott)
Comment on attachment 163078 [details] [diff] [review]
the patch if we choose to take it

This patch cannot land without code to import the existing profile locations
(don't move the files around, just recognize the existing location).
Attachment #163078 - Flags: review?(mscott) → review-
what about just making new profiles being created the correct place.
You can't do that, because profiles.ini would still be in the old location,
which defeats the purpose.
Default Thunderbird profiles should definitly move to
%AppData%/Mozilla/Thunderbird, Firefox is there, and so is Calendar now; this is
just inconsistent.

I would suggest that the installer checks for %AppData%/Mozilla Thunderbird, and
if it doesn't exist, just install into %AppData/Mozilla/Thunderbird.  If
%AppData%/Mozilla Thunderbird does exist, it should check for the profiles.ini
(or whatever files would indicate there is a functioning profile in there), and
use that.

Maybe if the user has chosen the "Custom" install option, than it should pop up
a warning and indicate possible alternative steps the user could take.

Either way, the above is too complicated, just have it check for the existence
of the older folder, use that if it finds it, else use the new
%AppData%/Mozilla/Thunderbird folder.
Priority: -- → P5
Flags: blocking-aviary2.0?
*** Bug 311520 has been marked as a duplicate of this bug. ***
Would this bug also cover the profile location on mac? Bug 318780.
Flags: blocking-firefox2? → blocking-thunderbird2?
Shouldn't this bug block Bugzilla Bug 259686
META: Firefox vs. Thunderbird consistency issues?
(In reply to comment #5)

> Linux: ~/.mozilla/Thunderbird
Small correction: in order to be consistent with FF, this should be ~/.mozilla/thunderbird 
It is maybe interesting that under Debian and Ubuntu, the profile is stored in ~/.mozilla-thunderbird and the binary is called "mozilla-thunderbird". 

When the profile location is changed, there should be a way to (automatically?) move old data to the new location, therefore it is necessary to be aware that ~/.thunderbird is not the only old location that could exist and should be detected.

There is a kb howto entry in the Ubuntu wiki that recommends copying from .mozilla-thunderbird to .thunderbird when installing Thunderbird from the binary package distributed from mozilla.org. This means that in some situations we might even find both .thunderbird and .mozilla-thunderbird and we probably need to ask which of those to migrate. 

We should also be aware that old profiles could be soft linked to any other location, including .mozilla/thunderbird 

Corresponding Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333509
Corresponding Ubuntu bug: https://launchpad.net/distros/ubuntu/+source/mozilla-thunderbird/+bug/47679
Component: General → Preferences
Assignee: benjamin → nobody
Severity: normal → trivial
Priority: P5 → --
(In reply to comment #25)
> Shouldn't this bug block Bugzilla Bug 259686
> META: Firefox vs. Thunderbird consistency issues?

Yes?


we can't fix this until we figure out comment 19
Flags: blocking-thunderbird2? → blocking-thunderbird2-
(In reply to comment #29)
> we can't fix this until we figure out comment 19
> 

I can't find an open bug for that. Is there one?
Just wondering: What is the problem with moving profile directories to the new location? Is that difficult? What exactly is described in comment 19?
Wouldn't it be better to alter the firefox from "%APPDATA%\Mozilla\Firefox" to just "%APPDATA%\Firefox" (and similarly on linux) to maintain the consistency?
Such an old bug that seems quite trivial to solve. Hope to see this one soon fixed.
I don't think this is worth fixing. Scott, please reopebn if you disagree.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
I definitely think it's a bug.

It's very inconsistent for there to be a mozilla/firefox folder, and then a mozilla-thunderbird folder.
(In reply to comment #34)
> I don't think this is worth fixing. Scott, please reopebn if you disagree.
> 
I think this is worth fixing. Previous comments provide some arguments why. I'd add that under linux there is usually some association between application and (hidden) config file, so either we have .firefox and .thunderbird or we gather all Gecko-based XULRunner-to-be applications under .mozilla. 
Consistency is important for issues like backing up data (all the emails are stored in that directory!!) and other things.

Do you have some argument to backup your opinion that it is not worth fixing? 
I think this is a bug as well, and should be fixed.  The lack of consistency between Firefox and Thunderbird in this regard as long irritated me.  I never bothered filing a bug for this in the past because I just assumed that it was being worked on and would be fixed in a future version, but after installing 2.0 and realizing that it's STILL stored differently than Firefox I just had to speak up.  I was going to file a bug report, but upon searching I found that a three-year-old bug was already open (and subsequently closed).

Firefox and Thunderbird are both official Mozilla products.  They share part of the same name, look the same, feel the same, store data mostly the same...  However, Firefox stores it's data in ~/.mozilla/firefox whereas Thunderbird uses ~/.thunderbird.  Why must this one thing remain different?  It would make much more sense to group Thunderbird under the Mozilla umbrella along with Firefox.  Alternatively, Firefox could be pulled out of the Mozilla hierarchy and stored separately as well, which would also be fine with me as Firefox and Thunderbird would be consistent at that point, but given that Firefox is currently the flagship Mozilla product it would make sense to adapt to its conventions.

Granted, I'll be the first to admit that this is a relatively minor issue that doesn't impact functionality in any way whatsoever, but as a hardcore Mozilla user I'd really, really like to see better consistency between the two products in this regard.  It'd also be more convenient for less technically inclined users as well, as they could always by pointed to ~/.mozilla (or %appdata\Mozilla) for any and all Mozilla-related profiles.  Consistency is a very good thing, and something that I'm sure all Mozilla developers, who put so much emphasis on this within the applications themselves, would agree.  Please reconsider the WONTFIX.

Thanks.
I think it's actually a little odd, and perhaps even disrespectful to the 47 people or so who've voted for this to be fixed and who've layed out very reasonable arguments for it, for you to simply come along and just call it WONTFIX without giving any reason why.

Care to share your reasoning, Benjamin?
2.0.0.0 would've actually been the perfect place to make the switch, really.  At a major version increment, it really would not've surprised anyone.
1) Thunderbird works perfectly fine now
2) Migrating existing profile locations is risky and would require lots of QA
3) Consistency with Firefox is not especially important; the apps are different

Votes don't really matter in this context: it's a question of risk/reward that Scott (as tbird owner) and myself (as toolkit owner) need to decide.
Addressing these points above:

(1) Works fine.  So do many things that are not technically correct.  The current folder locations for Thunderbird per-user data is not what Microsoft recommends and has tried to standardise on.  See http://support.microsoft.com/kb/310294# where it states quite clearly that:

"Store Application Data in the Correct Location
You use the SHGetFolderPath function to retrieve the correct Application Data folder. Do not store application data directly in this folder. Instead, use the PathAppend function to append a subfolder to the path that SHGetFolderPath returns. Make sure that you use the following convention:
Company Name\Product Name\Product Version
For example, the resultant full path may appear as follows:
\Documents and Settings\All Users\Application Data\My Company\My Product\1.0 "

Mozilla Firefox follows this convention, but not Mozilla Thunderbird, unless you consider "Thunderbird" to be a company name.

(2) It would surely not be risky to have TB look in BOTH locations (for a possibly lengthy period of time), so that the "more consistent" layout could be used but the legacy path continue to function.  New installations could use the new location, old ones would continue to work.  Would it really require that much QA to have TB look for profiles in two places?  Sure if you were going to migrate/move profiles on disk it would be more risky, but I am not suggesting that.


(3) If we don't care about consistency then why do we have trademarks like "Mozilla Thunderbird", and "Mozilla Firefox" and have a number of similar features?  That sure seems like some attempts at consistency within the various projects to me.


I hope this decision is at some stage reconsidered.


I really don't want this to become a nasty, flame-ish sort of debate.  I really do think this should be fixed.  I think a lot of other people do too.

(In reply to comment #40)
> 1) Thunderbird works perfectly fine now
I'm sure Microsoft was saying the same thing about IE6.  Just because it "works" is no reason not to improve it.

I feel Reuben made great responses to each of those three points.
 
> Votes don't really matter in this context: it's a question of risk/reward that
> Scott (as tbird owner) and myself (as toolkit owner) need to decide.
I am rather surprised to hear you feel this way, especially since oss generally thrives on community interaction.  But if you really feel that way, you might want to open a bug for Bugzilla then, something along the lines of, "Allows user unnecessary feedback."
(comment #22)
> I would suggest that the installer checks for %AppData%/Mozilla Thunderbird, and
> if it doesn't exist, just install into %AppData/Mozilla/Thunderbird.  If
> %AppData%/Mozilla Thunderbird does exist, it should check for the profiles.ini
> (or whatever files would indicate there is a functioning profile in there), and
> use that.

This is, I think, the best way to fix this bug.
If somebody comes up with a patch like that, maybe will it do the trick.
That's what I believe after reading comment #19.

1) As it stands, this is actually something that is broken in Thunderbird. Thunderbird does not "work fine" because it is putting its profiles in the wrong place. Standards are important - even if they are just for a small family of applications. Do we want Mozilla projects to degenerate into a host of fiefdoms each with its own directory, naming, and look and feel? Do we really want mozilla projects to devolve into the Unix "binaries everywhere" problem of /bin, /usr/bin, /opt/bin, /bin/bin, /usr/local/bin.....?

3) The fact that users have voted for it means that someone has wasted their time by "hiding" the profile and not keeping the profiles in a consistent location. In fact, the bug wasted enough of the user's time that he/she went online, searched the database for the request, found it, voted for it, and has been reading e-mails about it. When a bug wastes a user's time, it means the software is broken and needs to be fixed
The whole way how Mozilla-based/XULrunner applications store their configuration and user data is an ugly mess, inflexible, inconsistent and cryptic and what this bug proposes is only a small part of how this should really be fixed.

Anyone who has an interest in this getting solved should maybe get their arguments why changes are needed together and also think about how configuration data needs to be managed by users and non-Mozilla programs (e.g. backup, desktop search etc) and discuss this somewhere outside of Bugzilla (Mozillazine development forum?).

Once there is a good plan with real good arguments and maybe even a patch where the risk can be judged based on an actual solution, it is still possible to reopen a another bug for that general topic.

(In reply to comment #20)
> what about just making new profiles being created the correct place.

(In reply to comment #21)
> You can't do that, because profiles.ini would still be in the old location,
> which defeats the purpose.

I think they meant for new installations, going forward. This would be good to do on the trunk right now before it branches again.

I think they finally did this for Seamonkey. I suggest they reopen this bug for Thunderbird.

Bug 393620 – Change SeaMonkey Vendor ID to "Mozilla"
(1) Profile location of Seamonkey 1.1.4 is %APPDATA%\Mozilla directory (when MS Win-XP SP2).
(2) Seamonkey trunk had following in application.ini just before bug 393620.
> [App]
> Vendor=mozilla.org
> Name=SeaMonkey
Profile location was %APPDATA%\mozilla.org\Seamonkey at this stage.
(2) And it was changed to following by Bug 393620.
> [App]
> Vendor=Mozilla
> Name=SeaMonkey
Then profile location was changed from %APPDATA%\mozilla.org\Seamonkey to %APPDATA%\Mozilla\Seamonkey.

For change from (1) to (2)/(3), profile migrator was implemented, and profile of Seamonkey 1.x can be migrated when first start of Seamonkey trunk.
For change from (2) to (3), following document was prepared for nightly testers.
 http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla

Thunderbird 2.0.x doesn't have application.ini, and Thunderbird trunk currently doesn't have Vendor line in application.ini.
> [App]
> Name=Thunderbird
So profile location is %APPDATA%\Thunderbird currently.
Change to following will alter profile location to one which we are requesting - %APPDATA%\Mozilla\Thunderbird directory.
> [App]
> Vendor=Mozilla
> Name=Thunderbird
This change is similar to profile location change of Seamonkey;
  By upgrade from Semonkey 1.1.4 to Semonkey trunk nightly
  By vendor ID change from mozilla.org to Mozilla.

I think that, if migration support by Tb will be limited to "manual migration" only (e.g. tb-migrate.exe ProfName, can be called "profile location changer"), migrator logic will be kept simple.
 - No need to check exsistence of old/new profile directories and profiles
 - Actions required are not so many;
   - dead copy of profile directory
   - text string change from "Thunderbird" to "Mozilla\Thunderbird"
   - delete of panacea.dat etc.
These are same actions explained by wiki document for SM's vendor ID change.
  http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla
And Shell Script is already provided for Unix user to automate profile location change from ".../mozilla.org/Seamonkey" to ".../Mozilla/Seamonkey".

CC-ing to Mark Banner.
Mark, can your migration code of Seamonkey be easily ported to Thunderbird? 
(In reply to comment #49)
> CC-ing to Mark Banner.
> Mark, can your migration code of Seamonkey be easily ported to Thunderbird? 
> 
When I last looked at this bug/discussed it with Scott, all that needed to be changed was the vendor id in application.ini.

Due to the way thunderbird's profile migrator already works, for new installations, the profile manager will pick up thunderbird profiles that exists in "Thunderbird" and link to them direct from Mozilla\Thunderbird - i.e. no moving of files/directories needs to take place.

Of course, for new profiles the vendor id change will mean that the profiles are installed into Mozilla\Thunderbird.

You should be able to try this just by adjusting application.ini in a nightly build. I don't believe there would be a problem to existing users (especially as no files/directories would need copying/moving).
(In reply to comment #50)
> When I last looked at this bug/discussed it with Scott, all that needed to be
> changed was the vendor id in application.ini.

Adding "Vendor=Mozilla" to application.ini of a trunk nightly build under Linux the profile manager isn't able to find to existing profiles located under ~/.thunderbird. Using the import wizard shows that's also doesn't find the old profile data. Am I doing something wrong or isn't it as simple as you mentioned, Mark?
> Vendor=Mozilla  Name=Thunderbird  (Tb trunk 2007/10/05 build, MS Win-XP SP2)
Tb newly created profile of "Default" in new profile location. 
Following work was required to use profiles in old location.
 1. Copy profile.ini from old location to new location
 2. Change profile.ini entry from isRelative=0 and specify full path
    (I don't know how to specify new location in relative format)
I think current migration code of Tb is for "profile contents for new version" only, not for "profile location change".
Above 2. should be read; (sorry for spam)
 2. Change profile.ini entry TO isRelative=0 and specify full path
    (I don't know how to specify OLD location in relative format)
(In reply to comment #50)
> Due to the way thunderbird's profile migrator already works,

I've recalled about it...
Tb's profile migrator is for "from registry.dat(and older location?, 0.9 era?) to current profiles.ini & .../Thunderbird", isn't it?. 
(similar to current migrator from Sm 1.x to Sm trunk)
Adding of similar logic to shell script(for location change due to vendor ID change of SM) is very difficult? 
(In reply to comment #54)
> (In reply to comment #50)
> > Due to the way thunderbird's profile migrator already works,
> I've recalled about it...
> Tb's profile migrator is for "from registry.dat(and older location?, 0.9 era?)
> to current profiles.ini & .../Thunderbird", isn't it?. 
> (similar to current migrator from Sm 1.x to Sm trunk)

Yes, you're probably right there. Though the SM migrator from 1.x to trunk does work slightly differently - it forces the user to move the profile rather than re-using it from the current location.

> Adding of similar logic to shell script(for location change due to vendor ID
> change of SM) is very difficult? 

Its not a shell script you need to change. I think you would have to change this function:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mail/components/migration/src/nsProfileMigrator.cpp&rev=1.14&mark=193-296#193

to cope with both profiles.ini and registry.dat (note: try profiles.ini first, see also bug 383052), SeaMonkey has some code to load the profiles.ini/registry.dat here which may be useful:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/suite/profile/migration/src/nsNetscapeProfileMigratorBase.cpp&rev=1.15&mark=431-613#431
This bug is getting a lot of traffic for a "WONTFIX" bug.
Probably a good sign that it shouldn't be WONTFIX.
I third that. If someone could dome up with the step by step solution for the issue then I would mark this reopened.
If we got time for it it should block the next version too. 
I can give you a step-by-step plan for solving it, if you want, based on all the comments here.  But I'm not personally skilled enough to implement it.  And I'm happy to work with anyone who finds a problem with my plan.  Email me if you want (the link in my name has my address).
Inhibitor of "change to Vendor=Mozilla" is profile migration problem of current users only, and at least followings are to be considered.
 (A) What is moved.
     1. Move profiles.ini only to new location, use current profile directory
     2. Move profiles.ini and profile directory to new location
 (B) Decision on "How to move to new location"
     1. Stand alone "profile location changer" (Batch type manual move)
        - shell script is already available for Unix
         (for mozilla.org/Seamonkey => Mozilla/Seamonkey)
        - for Mac OS X, modification or porting is easy, I think
        - shell script can be converted to ".BAT" for Win, I think
     2. Stand alone "profile location changer" assisted by start up module
        - Warning when no profile at new location
        - User runs 1. manually
     3. Automatic profile location move when Tb is started with no parameter
        (Similar to current migrator of Seamonkey trunk)
        - Move one profile only, to profile named "default"
        - If user uses multiple profiles, manual run of "... -migrate ProfName"
     4. Automatic profile location move and profile migration, any to any
        (Enhancement requests exist for migrator of Seamonkey trunk)
        - Move any old profiles, to any location, to any profile name  
        - Migrate from profile of any product 
 (C) Who can implement (B). Who will implement (B).

Main reason of WONTFIX was "hard to implement (B)", I think. But, as Worcester12345 said in Comment #47, there is very good example of Seamonkey now. So I think hardle is lower than one when decided to WONTFIX, although biggest problem of (C) was/is/will be there always when Tb/mail&news :-) 
Very nice summary.

Is there any reason we can't do B.1, with the script "piggy-backing" on the updater (the updater runs it after it does all it's other tasks)?

Is there any reason not to do it this way?
(In reply to comment #60)
>  (B) Decision on "How to move to new location"

You missed the point which I made previously which I believe would actually get a patch accepted:

5. NO PROFILE MOVE but reference a RELATIVE location for existing profiles.

This means that:
- New Profiles are created in the correct place.
- Existing Profiles aren't moved. No file copying/moving. Nothing to mess up. Nothing to miss out. Just referenced from where they currently exist.

However this still needs approval. Cc'ing mscott and reverting to default QA as they seemed to have got lost from this bug.
QA Contact: preferences
Comment from a user POV - I *want* my profile moving.

It's a non-trivial exercise to either a) move it manually or b) create a new profile and import all the settings.

If the profile can be moved in an automated and sane fashion whilst changing the default profile location then go for it I say.
It should be noted that a profile move should be fast since the files stay on the same disk (only the metadatas are modified).
(In reply to comment #62)
> >  (B) Decision on "How to move to new location"
> You missed the point which I made previously which I believe would actually get a patch accepted:

Mark Banner, please don't misunderstand my summary.
If you will be a person of (C), I believe patch will be created at a glance, since when I CC:'ed you by my Comment #49 expecting you to raise your hand.
But, if I will have to become a person of (C) in order to re-open this bug ASAP, I can do B.1 only. This is the reason why I still refer to B.1.
Biggest problem in volunteer based software development is always "Who will do it in short term".
To Mark Banner:
Can you take enhancement request if I open bug for "profile location change support by Thunderbird"? If no, who can take it? If yes, when can it be implemented?
(In reply to comment #66)
> To Mark Banner:
> Can you take enhancement request if I open bug for "profile location change
> support by Thunderbird"? If no, who can take it? If yes, when can it be
> implemented?

If Scott/David agree that my suggestion in comment 62 is acceptable, then I would be able to do it relatively quickly when I can find the time. I won't do it without knowing that they are going to be happy with/want the end result.
Blocks: 318780
Seeing that Thunderbird no longer is developed by Mozilla Corp., but by "some" external company or whatever you want to call it, I don't think that such a change should be done anymore.
"Mozilla Messaging" is the name of the "external company". It has "Mozilla" in it's name. So I can't see your problem.

I agree with Norbert, and it is said "We work with a global community of like-minded individuals and companies as part of the Mozilla project."
Source: http://www.mozillamessaging
I filed bug 424641 for the profile migrator work.
Version: unspecified → Trunk
Mark Banner added a patch on bug 424641 which makes old profiles available for the new location.

Benjamin, could we reopen this bug again? Seems that a possible solution is ongoing which helps to fix this issue.
A Thunderbird owner/peer can reopen this. I personally don't think it's worth doing, but I'm not a tbird owner.
Reopening - I do think we want to play nicely like all the other moz applications, assuming we get a safe patch of course.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Nominating wanted-thunderbird3 to keep it on the radar.
Flags: wanted-thunderbird3?
Taking, I think the patch for this is on bug 424641, if anyone can give it a go on Windows that'd be useful. Then I just need to finish doing the tinderbox changes.
Assignee: nobody → bugzilla
Status: REOPENED → NEW
Imho this ticket is invalid and all mozilla products should adopt the freedesktop XDG specification.

Please read http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

The XDG spec basically defines a set of (user-customizable) directories where each program can store user preferences and data separately (and cache separately too).

This has several advantages, I won't go in detail here.  There is already a ticket requesting XDG support @  https://bugzilla.mozilla.org/show_bug.cgi?id=259356
> Imho this ticket is invalid and all mozilla products should adopt the
> freedesktop XDG specification.

+1.

If you've got to move ~/.thunderbird, it's better to do it right at once.
(In reply to comment #79)
> > Imho this ticket is invalid and all mozilla products should adopt the
> > freedesktop XDG specification.
> 
> If you've got to move ~/.thunderbird, it's better to do it right at once.

We won't be doing this here. The priority for Thunderbird is for it to be the same as other mozilla products, so that we can reduce forked code and be consistent, at least within the mozilla products.

If you want to get the mozilla products matching the freedesktop specification then you should bring this up/discuss in the newsgroups (mozilla.dev.platforms.linux) and/or vote for bug 259356 (but not post unnecessary comments as per https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) as bug 259356, and hence Thunderbird as well.
(In reply to comment #78)
> Imho this ticket is invalid and all mozilla products should adopt the
> freedesktop XDG specification.
> 
> Please read
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> The XDG spec basically defines a set of (user-customizable) directories where
> each program can store user preferences and data separately (and cache
> separately too).
> 
<snip>

Even if Mozilla adopted the XDG spec; it still wouldn't solve this problem, since Moz still needs to have a directory structure under $XDG_CONFIG/DATA_HOME, and if we just ported the products over as is, Thunderbird would still be separated from other Mozilla products.

So really, your comment in this case is irrelevant, since the bug in question here is making Thunderbird follow the same conventions as other Mozilla products, regardless of what those conventions are.  See Mark's comment if you want to change the Mozilla convention as a whole.
Priority: -- → P4
I've been expecting the change from Thunderbird to Mozilla/Thunderbird in WinXP since TB 1.5.0. I already have FF, TB and Sunbird profiles in one folder outside %USERPROFILE% but it's just um... anoying and doesn't feel good to have one more folder under %APPDATA%. I hope this issue will be gone in TB 3.0.
Flags: wanted-thunderbird3?
I'm pretty sure the previous commenter didn't intend to clear the flag. Approving as wanted-tb3 anyway.
Flags: wanted-thunderbird3+
Flags: wanted-thunderbird3+ → wanted-thunderbird3-
noting that palmsync should be retested with trunk on XP and the longer path name implied by this bug and bug 424641.  The reason is palmsync requires path to conduits <110 characters and adding "Mozilla" to the path name will likely force palmsync extension to fail/fall back to "8.3 name" every user.  This was implemented in bug 322628 - bug 322628 comment 29 states 8.3 naming saves about 20 characters, which should be enough to keep it working for most users if not all, *if* everything in that patch works correctly.

Myself for example, the path to palm conduit is 

XP
         1         2         3         4         5         6
123456789012345678901234567890123456789012345678901234567890
C:\Documents and Settings\XXXX.AD\Application Data\Thunderbi
rd\Profiles\f3zfczyu.default\extensions\p@m  103 characters

vista is not at risk
         1         2         3         4         5         6
123456789012345678901234567890123456789012345678901234567890
C:\Users\XXXX.AD\AppData\Roaming\Thunderbird\Profiles\4jc4ur
c0.default\extensions\p@m  85 characters
I'm not working on this at the moment, reassign to default assignee, see bug 424641 for some of the issues with being able to fix this.
Assignee: bugzilla → nobody
Priority: P4 → --
Whiteboard: See bug 424641 for the issues in implementing this
I looked over 424641 and couldn't figure out why this is so hard to do. Having the Thunderbird folder in the wrong place is confusing to people; I just got hassled again by someone who couldn't find it when they needed to nuke a profile to start over, so I came looking for this bug to find out if there are any plans to fix this anytime soon. Doesn't look like it.
Sorry you couldn't figure it out - if you're planning on working on the patch, I'm sure Mark would be happy to help you understand where he ran into trouble.
Can someone add the "helpwanted" key word?
(In reply to comment #90)
> Can someone add the "helpwanted" key word?

are you saying you need someone's advice to code the patch?
Severity: trivial → normal
Whiteboard: See bug 424641 for the issues in implementing this → [patchlove][has draft patch][needs new assignee][See bug 424641 for implementation issues]
(In reply to comment #90)
> Can someone add the "helpwanted" key word?

From my perspective, the cost/benefit ratio doesn't currently warrant a helpwanted keyword. That said, I wouldn't stop someone working on this if they wanted to try and fix the issues in core (see bug 424641 for more info).
Comment on attachment 163078 [details] [diff] [review]
the patch if we choose to take it

Setting to obsolete, due to r-..
Attachment #163078 - Attachment is obsolete: true
Blocks: 458581
As stated above, if you're gonna move it, it shouldbe to the right place [1]. If you care about consistency between mozilla products, you should know that this is already in the works for firefox [2].

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
I agree with Comment 94; under *nix the profile data should move to a standard location rather than cluttering the user's home directory with yet another dot-directory.  Bug 259356 is specific to Firefox; should a new bug be opened for this request, or should discussion remain here?
XDG basedir support should be a in seperate request. 

It would be great to get xdg basedir support, but for now, move ~/.thunderbird to ~/.mozilla/thunderbird is much more necessary than that.
OK, XDG Base Directory support has been raised as Bug 735285.  Not sure whether how the bug dependency/blocking should be set (if at all).
Summary: Profiles should be stored under "Mozilla/Thunderbird" not "Thunderbird" → Profiles should be stored under "Mozilla/Thunderbird" not "Thunderbird" (no vendor set)
Component: Preferences → OS Integration
QA Contact: Tobias.Besemer
Some strange behavior with roaming profiles on network shares, in 1 case, 2 users' profiles show up on a MS SQL server C:drive, consuming quite a bit of space.

Will profile locations EVER be locked down or standardized?
Today that Mozilla does not feel associated with Thunderbird very much (the project is healthy but run under independent governance), it is quite questionable whether making the requested change has any sense for the future. We may even be forbidden to create Mozilla branded folders at this time.
Flags: needinfo?(rkent)
Flags: needinfo?(Tobias.Besemer)
Given that this did not happen much earlier, and that regardless of where we end up in 2016 we should strive to keep Thunderbird as a brand name independent of Mozilla, I think it is finally time to WONTFIX this.
Status: NEW → RESOLVED
Closed: 18 years ago → 9 years ago
Resolution: --- → WONTFIX
Don't think so!

As long TB is still developed and shipped via Mozilla.org, IMHO this should be fixed (ASAP)!

Seems like also the Seamonkey Profiles are still saved under "Mozilla":
http://kb.mozillazine.org/Profile_folder_-_SeaMonkey

Guess the reason that nobody have fixed this so far is, that program a solution is "just a boring task that need to much time" ... ;-)
Anyway, think this bug should be reopened and fix ASAP (at least because of QA)!
Flags: needinfo?(Tobias.Besemer) → needinfo?(acelists)
We're certainly not going to do this while we are in the middle of discussions about a long-term future. If the decision is made for Mozilla to keep Thunderbird, feel free to reopen this bug.
Flags: needinfo?(rkent)
As someone who works in QA and documentation, I'm in agreement with kent.
Status: RESOLVED → VERIFIED
Flags: needinfo?(acelists)
QA Contact: Tobias.Besemer
Whiteboard: [patchlove][has draft patch][needs new assignee][See bug 424641 for implementation issues] → [See bug 424641 for implementation issues]

I agree that those who agree agree on the wrong.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: