User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:18.104.22.168pre) Gecko/20071126 Ubuntu/dapper-security Firefox/22.214.171.124pre Build Identifier: 126.96.36.199 This happened when tidying up an older german TB installation. Both the profile manager window and profiles.ini showed four profiles, named "default", "Standard-Benutzer", "ufficio", "Büro". In profile.ini, the entries "default" and "ufficio" pointed to an existing profile directory, named "something.default" and "something.ufficio". The other ones did not point to any directory. I checked the profile named "default" to be the one that really was in use, by starting the profile manager, selecting de "default" profile and starting TB. Everything was allright. Since only the "default" profile was in use (all the others resulted from several tests), all unused profiles were to be removed. There was no reason to keep their files. So in the profile manager, I chose the button "delete files" (german: "Dateien löschen"). When deleting the profile named "Standard-Benutzer", the complete content of "something.default" profile directory was immediatly deleted (I had a file manager open in the background and watched the directory's entry dissappear). Everything was lost. :-( I did not try to reproduce this with a freshly setup TB, since I assume that this problem only may appear on installations which have been in use some time. Anyway, there must be something wrong with the "delete files" option. I don't know what profile.ini entries whithout directory specification are made for. Neither I know, why there has been profiles named "Standard-Benutzer" and "default". "Standard-Benutzer" might have been a result from importing an MS Outlook e-mail database, I could imagine. Reproducible: Didn't try No themes, no extensions except spell checker.
(In reply to comment #0) > The other ones did not point to any directory. What do you mean by "not point to any directory"? Because you say next, > I don't know what profile.ini entries without directory specification are made for. it sounds for me no "Path=..." line for the "other ones". I tested with following profile.ini of absolute path(left one. on MS Win). When BAD-PROF was deleted by profile manager, C:\TEST\MOZ-PROF\PROFS" was deleted, then directory for Profile0(C:\TEST\MOZ-PROF\PROFS\PROF-01) vanished. If IsRelative=1 & Path=Profile, I think similar situation to above will occur. Sorry but I don't know "no Path= line" case or "Path= only line" case. >(Tested profile.ini) (Possible profile.ini) > [Profile0] [Profile0] > Name=MOZ-PROF@PROF-01 Name=PROF-01 > IsRelative=0 IsRelative=1 > Path=C:\TEST\MOZ-PROF\PROFS\PROF-01 Path=Profile/abcdefg.PROF-01 > [Profile1] [Profile1] > Name=BAD-PROF Name=BAD-PROF-A > IsRelative=0 IsRelative=1 > Path=C:\TEST\MOZ-PROF\PROFS Path=Profile > [Profile2] > Name=BAD-PROF-B > IsRelative=1 > [Profile3] > Name=BAD-PROF-C > IsRelative=1 > Path=
Moving to what passes for the "Toolkit: Profile Manager" component, until we finally get the long-promised reorganization. Pay no attention to the way it looks like it's in Firefox ;)
Component: Account Manager → Startup and Profile System
Product: Thunderbird → Firefox
QA Contact: account-manager → startup
Version: 2.0 → 2.0 Branch
(In reply to comment #1) > What do you mean by "not point to any directory"? Hm, I must admit, I do not remember exactly. Actually your examples let me think, that most likely there have been lines like "Path=Profilename" in those two cases of "Standard-Benutzer" and "Büro"; so the entries may have been "Path=Standard-Benutzer" and "Path=Büro". I'm very sorry, but I can't tell exactly. I do remember that all entries have been relative ("IsRelative=1").
Following is Tb trunk's behaviour. (2008/01/02 build). (Relative Profile : Case-1) > [ProfileA] > Name=BAD-PROF-A => If no 'Path=' line, entry is removed from profile.ini, > IsRelative=1 and is not displayed in profile manager's panel. > [ProfileB] => When 'Path=' only, entry was changed to absolute. > Name=BAD-PROF-B Name=BAD-PROF-B > IsRelative=1 IsRelative=0 > Path= Path=%APPDATA%\Thunderbird > > %APPDATA% part when MS Win-XP : > C:\Documents and Settings\<uerid>\Application Data When BAD-PROF-B case, Tb will try to delete .../Thunderbird directory. Then .../Thunderbird/Profiles directory will be deleted. But, because .../Thunderbird/profile.ini is opened by profile manager himself, .../Thunderbird directory will probably not be deleted. (Relative Profile : Case-2) > [ProfileX)] > Name=PROF-X > IsRelative=1 > Path=PROF-DIR ( %APPDATA%\Thunderbird\PROF-DIR ) > [ProfileY] > Name=PROF-Y > IsRelative=1 > Path=PROF-DIR/SUB ( %APPDATA%\Thunderbird\PROF-DIR\SUB ) > [ProfileZ] > Name=PROF-Z > IsRelative=1 > Path=PROF-DIR/SUB/SUB-SUB ( %APPDATA%\Thunderbird\PROF-DIR\SUB\SUB-SUB ) Tb worked well with any above profile entry. (Realtive profile directroy works very well.) Delete of PROF-X will delete directories for other profiles.
In any test case, it was impossible to see situation of "not point to any directory", except just after manual change of "Path=..." to "Path="(or manual remove of "Path=..." line). And, if "Path=..." pointed to non-existent directory, trying to start with the profile caused "profile is in-use" error(this is already reported phenomenon.) To Martin Schniewind(bug opener): Did you modify profile.ini content manually in the past?
(In reply to comment #5) > Did you modify profile.ini content manually in the past? > I didn't. All this happened on a customer's machine. I know him well enough to tell he would not manipulate a text file by hand. So I tend to say: no, nobody modified profile.ini.
I can confirm this bug. happend to me yesterday. The profilemanager went into somekind of endless loop ( windows thought it was froozen ) , in the end, it deleted all profiles on disk in a way, it wasn't possible to undelete them ! No Trashcan, no lost files on disk. Wiped clean. I whised all file deletes would do that trick :) Sys: Windows XP SP 2 FF: 23.0.1
Cannot reproduce. Here is what I did: 1. Start "C:\Program Files (x86)\Nightly\firefox.exe" -no-remote -P 2. Create new profile "1" 3. Start Firefox with "1" 4. Start again "C:\Program Files (x86)\Nightly\firefox.exe" -no-remote -P 5. Delete "1" and start Firefox with the default profile Actual results: Firefox starts ok.
You need to log in before you can comment on or make changes to this bug.