Closed Bug 278860 Opened 20 years ago Closed 12 years ago

confusing "profile in use"/"already running" error when profile is missing (not found)

Categories

(Toolkit :: Startup and Profile System, defect, P3)

Product:
Toolkit
Component:
Startup and Profile System
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla14
Tracking Flags:
Tracking Status
firefox14 + verified

People

(Reporter: joshkel, Assigned: mkaply)

References

(Blocks 2 open bugs)

Details

(Keywords: ux-error-recovery, Whiteboard: [pm-ui])

Attachments

(2 files, 5 obsolete files)

Add directory check in three places
1.81 KB, patch
benjamin
: review+
mfinkle
: approval-mozilla-central+
Details | Diff | Splinter Review
Fix for gPromptService problem
581 bytes, patch
mossop
: review+
Gavin
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

If Thunderbird is configured to store its profile on a network drive, and if the
network drive is not connected when Thunderbird starts, it brings up the Profile
Manager and says that it cannot load the profile because it is in use.

Reproducible: Always

Steps to Reproduce:
1. Configure Thunderbird with a profile on a network drive.
2. Exit Thunderbird and disconnect the network drive.
3. Restart Thunderbird and attempt to load the profile that's on the network drive.

Actual Results:  
Thunderbird reports that the profile is in use.

Expected Results:  
Thunderbird reports that the profile directory cannot be found.  Ideally, it
might report that the drive cannot be found and give the directory that it's
looking for to help the user in diagnosing the problem.

I've seen this problem in Firefox 1.0 and Thunderbird 1.0.  It does not occur in
Mozilla 1.8a5; maybe it's been fixed there?  I apologize if it's already fixed
in the development version.
Assignee: mscott → nobody
Component: General → Profile: BackEnd
Product: Thunderbird → Core
QA Contact: profile-manager-backend
Version: unspecified → Trunk
Good bug report, this is one of the many startup UI bugs that I intend to fix,
with lots of luck before 1.1.
Assignee: nobody → benjamin
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Profile: BackEnd → XRE Startup
Ever confirmed: true
Product: Core → Toolkit
Whiteboard: [pm-ui]
Version: Trunk → unspecified
Priority: -- → P3
*** Bug 294963 has been marked as a duplicate of this bug. ***
The error message is wrong. Doing something clever when the profile can't be
found might be an enhancement, but in the first instance it's a bug.
Severity: enhancement → normal
*** Bug 307951 has been marked as a duplicate of this bug. ***
*** Bug 297142 has been marked as a duplicate of this bug. ***
*** Bug 312728 has been marked as a duplicate of this bug. ***
*** Bug 312817 has been marked as a duplicate of this bug. ***
*** Bug 311749 has been marked as a duplicate of this bug. ***
*** Bug 305923 has been marked as a duplicate of this bug. ***
Many bugs duped to this one see behavior similar to the following.  You can also find several posts in Mozillazine's forums if you search for the error message below.

Firefox 1.5:

1)  Firefox not running

2)  Rename profile folder

3)  Start Firefox

4)  Displays window:

"Firefox is already running, but not responding. To open a new window, you must
first close the existing firefox process, or restart your system"
*** Bug 320241 has been marked as a duplicate of this bug. ***
Summary: "profile in use" when profile drive is missing → confusing "profile in use" error when profile is missing (not found)
Occurs in all aviary apps (Firefox, Thunderbird, Sunbird)
There are two misleading error dialogs.

1. Create a new profile, say called test2:
   firefox.exe -p
   Create Profile
   test2

2. Exit firefox.

3. Delete test2 profile directory manually (name ends with .test2).

4. Start firefox.exe
Get dialog with misdiagnosis:

+---------------------------------------------------------------------+
 Close Firefox                                                      
   Firefox is already running, but is not responding.  To open a new
   window, you must first close the existing Firebird process, or    
   restart your system.                                              
+---------------------------------------------------------------------+

5. Start firefox.exe -p test2
Same "Close Firefox" message as #4.

6. Start firefox.exe -p
   Profile manager appears: select profile test2.

Get dialog with misdiagnosis:

+--------------------------------------------------------------------+
 Profile in Use                                                     
   Firefox Cannot use the profile "test2" because it is in use.
   To continue, close the running instance of Firefox or choose a
   different profile                                          
+--------------------------------------------------------------------+

WORKAROUND: (if profile is to be deleted, not just disconnected.)
9. Start firefox.exe -p
   Profile manager appears: delete profile test2.
   Create a new profile, or select a previously existing profile.

(Initial search for comments with these error messages did not turn up
this bug because 'is' was missing from comment 10.)

Messages are in 
http://lxr.mozilla.org/mozilla/source/toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties

First dialog appears to be displayed by ProfileLockedDialog.
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1226

ProfileLockedDialog called when lock fails for any reason (CPP).
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1473
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1553
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1603

Second dialog also appears when lock fails for any reason (JavaScript).
http://lxr.mozilla.org/mozilla/source/toolkit/profile/content/profileSelection.js#122

Simple solution would be to broaden the messages to account for other reasons the lock operation can fail.  More involved solution would check if directory exists and give an alternate message if not.

Simple combined messages might be something like

+--------------------------------------------------------------------+
 Profile Unavailable

  The profile may either be locked or unreachable.  If it is locked by
  an existing Firefox process, you must first close Firefox or restart
  your system.
+--------------------------------------------------------------------+

+--------------------------------------------------------------------+
 Profile "test2" Unavailable

  The profile "test2" may either be locked or unreachable.  If it is
  in use, close the running instance of Firefox or choose a different
  profile.
+--------------------------------------------------------------------+

Hope this helps.

I don't really understand about finding the identities and all of that, but my saved bookmarks and tabs appear to be gone and I don't know how to change the "user" - it said that my name was in use (it wasn't) and that I had to make up a new name, so I did - and now I have nothing. Please help.
I am using Windows XP and Firefox.

Thank you!
*** Bug 324764 has been marked as a duplicate of this bug. ***
*** Bug 325559 has been marked as a duplicate of this bug. ***
*** Bug 325693 has been marked as a duplicate of this bug. ***
*** Bug 325950 has been marked as a duplicate of this bug. ***
same problem here. i use multiple profiles and they are not always available. iirc  old versions of firefox displayed the profile manager if the profile was not found - it would be very nice, if this would be like this again. perhaps the profile manager could have some field with the error message, that the profile wasn't found?

(FF 1.5.0.1, WinXP SP2)
*** Bug 332505 has been marked as a duplicate of this bug. ***
Comments transferred from duplicate 332505:

If the profile folder cannot be found on program startup, the user gets the "firefox is already running" message. Since profiles.ini persists through reboot and reinstall, and profile folder is only ever created by the installer in the default location and not in the location pointed to by profiles.ini, the problem persists during reboot and reinstall.

Steps to reproduce: Quit firefox. Rename profile folder (as linked from profiles.ini) to some other name (eg "profile.temp") and try to run firefox. Program will not start up. Error message "Firefox is already running". Rename the profile folder back to same name as in profiles.ini, and it works again.

Analysis: When firefox reinstalled, the installer did NOT recreate profiles.ini. Instead, it seems it had noted there was an existing profiles.ini and left it as it was. Since I'd deleted the old profile in anticipation of reinstall, hence on program startup it couldn't find the profiles folder and failed to start as above. The flaw is primarily in the installer, it EITHER does not rewrite  rofiles.ini to point to the profiles folder, OR does not check the profile folder actually exists and is valid. But it should also be caught on program startup too, in cae of a disconnected or deleted profile folder.

Further observation #2: What would happen if the folder pointed to existed from an old install, or existed but contained certain corrupt data? Would the user be stuck with a mysteriously failing firefox that no matter how often they reinstalled failed to run correctly? Should the installer ask for a profile folder location, or check if it already exists whether to create a new (empty) one?
I think the allocation should be changed to major: any issue that means a program can be blocked from launching and persists past reinstall and reboot, and whose explanation and solution (via profile manager) is on an obscure page of the mozilla wiki that you have to know exists to find out about, is not a "normal" level of issue.

At the very least the error message needs updating to explain that profile issues can cause this error, see LINK, so users who get it can solve it, and also the profile manager shortcut should be added to the Fx start menu since its a function many people will find useful.
This is not limited to Windows XP.  I just had the following situation: my Linux box crashed (yes, it does happen, especially when one presses the reset button).  Two lock files were left in the profile (lock and .parentlock, I think); on rebooting, I got the incorrect message "Firefox is already running, but not responding." The message which went on to suggest that I close firefox (which wasn't running; yes, I checked with ps) or restart my computer (which I had just done and in any case would have had no effect on the two lock files).

A link to solutions to the problem would have been nice, but as a general rule might not be so useful if firefox is the only browser on the machine.
*** Bug 334953 has been marked as a duplicate of this bug. ***
Sure, if I had meticulously followed http://www.mozilla.org/support/firefox/profile#move , this wouldn't have happened to me.

But being able to take your profile with you when you move from an old to a new computer ought to be more fool-proof!
While the Thunderbird message is somewhat meaningful, the equivalent Firefox message is completely misleading:

   "Firefox is already running but is not responding. To open a new window,
    you must first close the existing Firefox process, or restart your system."

I totally agree with comment #21 (from Fox2). The priority should be changed to major, at least until the error message is fixed at which point it can changed back to normal. 

In addition to the "deleted profile", "renamed profile", and "profile on unavailable network drive" scenarios already mentioned, one can run into the same problem by using a profile on a USB memory device, exiting Firefox, removing the USB device, and trying to restart Firefox. Hence, one more reason to fix the problem.
*** Bug 345946 has been marked as a duplicate of this bug. ***
*** Bug 345945 has been marked as a duplicate of this bug. ***
*** Bug 348767 has been marked as a duplicate of this bug. ***
*** Bug 350327 has been marked as a duplicate of this bug. ***
This was also a regular issue for student users in our Mac OS X computer labs -  we started to get complaints in February 2006.  They all have network home directories mounted from a remote file server and Firefox frequently failed to clean up its lock files on exit, or logout.  As a workaround we provided a login hook which searches their profile and deletes any lock files.  Fewer students use Thunderbird, but they get the "profile is in use" message and call for help.

Firefox and Thunderbird have both had their wings clipped by this one.  The bug is still there and so is our crude workaround.  Here is our login hook which runs as the user logging in:

#! /bin/sh

# Remove all Firefox lock files created from the current IP address

# Discover the IP address of the ethernet interface on this machine
ipAddress=`/sbin/ifconfig en0 | /usr/bin/sed -ne '/inet /p' | /usr/bin/cut -d" " -f2`

# First argument passed to login hook is the path to the user's home directory
userHomeDir=$1

/usr/bin/find $userHomeDir/Library/Application\ Support/Firefox/Profiles -name "${ipAddress}:[0-9]*" -exec /bin/rm {} \;
/usr/bin/find $userHomeDir/Library/Application\ Support/Firefox/Profiles -name ".parentlock" -exec /bin/rm {} \;

exit

Is this bug going to be addressed?  Way back on February 4, 2005, Benjamin Smedberg wrote: "Good bug report, this is one of the many startup UI bugs that I intend to fix, with lots of luck before 1.1."

It's now September 23, 2006, Thunderbird 2 has entered Alpha, Firefox 2 is pushing RC1, and the bug is just as fresh as February 4, 2005.  Not that I know how to fix it. :-)
Assignee: benjamin → nobody
*** Bug 356642 has been marked as a duplicate of this bug. ***
Most of the dupes talk about "already running" -updating summary. Seems that what it says nowadays...
Summary: confusing "profile in use" error when profile is missing (not found) → confusing "profile in use"/"already running" error when profile is missing (not found)
*** Bug 362130 has been marked as a duplicate of this bug. ***
*** Bug 362537 has been marked as a duplicate of this bug. ***
*** Bug 362817 has been marked as a duplicate of this bug. ***
*** Bug 364199 has been marked as a duplicate of this bug. ***
Seems that this bug was forgotten. Benjamin, any change to get this in?
Flags: blocking1.8.1.2?
If somebody provides a patch, I'd be happy to review it. This does not block any releases.
Flags: blocking1.8.1.2? → blocking1.8.1.2-
Hi,

It's maybe a good idea to  add a warning in http://kb.mozillazine.org/Moving_your_profile_folder, until the bug is removed. 

Something like "Warning: due to bug 278860, thunderbird will repport the wrong error "Firefox is already running, but is not responding.[...]" wenn misspelling your directory. Whenn this error occurs, first check the .ini file you modified"

(ps: I tried to submit this in the online help using [edit], but my account did not work.)
(In reply to comment #40)
> Hi,
> 
> It's maybe a good idea to  add a warning in
> http://kb.mozillazine.org/Moving_your_profile_folder, until the bug is removed. 
> 
Done.

The Firefox or Thunderbird "already running but is not responding" error can also occur if the wrong profile path is entered after the "-profile" command line argument. This can result in the "already running" error when a user incorrectly tries to start the Profile Manager from the command line using "-profile manager" instead of "-profilemanager".  I also added a note about that to http://kb.mozillazine.org/Profile_Manager#Accessing_the_Profile_Manager 


ccing mconnor - I remember him saying something about wanting "polish" bugs for 3 and I believe this one would count.

What all needs to be done? Does the code detect that the profile is missing but is falling back on a poor error dialog?
OS: Windows XP → All
Hardware: PC → All
Right now it basically detects that it couldn't lock the profile. This happens to be because the profile folder doesn't exist, rather than because the profile is already locked. It wouldn't be hard to add an explicit check for existence and propagate that error code back.
(In reply to comment #45)
> to be because the profile folder doesn't exist, rather than because the profile
> is already locked. It wouldn't be hard to add an explicit check for existence

Further it also happens for profiles which are located on network shares. If you wake up your computer and no other software has used the mapped drive before you start Firefox or Thunderbird it will also fail.


What do you think about changing the message error to have something more explicit like "Thunderbird could not open the profile file xxx in read/write mode, please check filename, filelocation and write possibility"
(In reply to comment #46)
> (In reply to comment #45)

>Absolutely right Henrik, 

All of our Thunderbird email profiles are mapped to m:\ on a file server for centralised email backup.

If the network drive M:\ is not initialised by another program first on the local computer,then TB reports "Profile in use". This was totally misleading. 

What it should say is "Network drive unavailable, cannot load profile". But even that isn't quite true, because it was available. TB just hadn't initialsed the network M:\ before looking for the profile.

My work around is to have another program look at M:\ first. After this TB can see m:\, and it's profile. I use windows explorer in start up to do this.

The program fix should have TB look at the network drives, initialise them, then look for the profile. This would really help with wireless network drives which we use and occasionally go down.
Attached patch Change the wording of the dialog (obsolete) — — Splinter Review 
While (and/or because) the backend can't make the difference for now, let's just change the wording.
I suggest 
>Profile In Use Or Inaccessible
for the title and
>%S cannot use the profile "%S" because it is in use or inaccessible.\n\nTo >continue, close the running instance of %S, choose a different profile or make >this one accessible.
for the content.
Attachment #281283 - Flags: review?
Why doesn't somebody just write a patch to propagate and test for the error? This isn't rocket science, it just needs a coder.
Severity: normal → major
When we are trying to lock the profile, we don't differentiate between the different Exceptions which could be thrown by nsProfileLock:

http://mxr.mozilla.org/seamonkey/source/toolkit/profile/content/profileSelection.js#120
http://mxr.mozilla.org/seamonkey/source/profile/dirserviceprovider/src/nsProfileLock.cpp#143

Someone should add code to differentiate between the thrown Exceptions.

Axel, are these late l10n changes already possible or is it too late for Firefox 3?
Right now, I don't think that l10n impact governs that decision. Whether we'd take this patch for M10 or not is likely going to be based on a risk analysis, I doubt it has an severe l10n impact.
This patch contains string changes and will impact l10n.

Before we try to lock the profile we should check if the given path is accessible and is a directory. That will stop all other exceptions. I combined both checks into one alert message.
Assignee: nobody → hskupin
Attachment #281283 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #287869 - Flags: review?(benjamin)
Attachment #281283 - Flags: review?
QA Contact: profile-manager-backend → xre.startup
> +profileNotAccessible=%S cannot use the profile "%S" because its given path is not accessible or contains no profile data files.

AFAIK you can also use an empty directory without causing any problems. So "or contains no profile data files" seems to be not needed. You are not checking for empty directories, too.
> AFAIK you can also use an empty directory without causing any problems. So "or
> contains no profile data files" seems to be not needed. You are not checking
> for empty directories, too.

You are right. An empty directory works fine. I've removed the second part of the sentence.

But anyway I would like to wait what Benjamin says in general before updating the patch once more.
Attachment #287869 - Attachment is obsolete: true
Attachment #287885 - Flags: review?(benjamin)
Attachment #287869 - Flags: review?(benjamin)
Is there a different message for when the directory doesn't exist? That doesn't work, I thought the second bit of the string was in reference to that.
No, it's the same message. If the given path doesn't exist or isn't a directory the alert will be shown. I have to test for existence first because I get an exception otherwise when only calling isDirectory. 
Comment on attachment 287885 [details] [diff] [review]
Patch v1.1: Same as v1.0 without mentioning missing profile data

This is not the correct place for this code (or at least it's not sufficient). If you launch with -P test we need the error-checking to occur here: http://mxr.mozilla.org/mozilla/source/profile/dirserviceprovider/src/nsProfileLock.cpp#262 and here: http://mxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1908
Attachment #287885 - Flags: review?(benjamin) → review-
Benjamin, just a question before I have a look into the cpp files... Do the Profile Manager and command line switch share some backend code, so all the js stuff I made can be moved there? Or do we definitely need my patch for the PM?

Runing Firefox with the switch -p and a profile which points to an invalid directory shows me an empty dialog on OS X. Also if it's already locked I get a different message as on Win/Lin. I searched mxr and found following code:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/xre/nsAppRunner.cpp&rev=1.198&mark=1645-1651#1645

Does checking for an invalid directory and its output also needs different implementation?
Normal usage is hidden behind the profile-locking code which is called from nsIToolkitProfileService.lockProfilePath or nsIToolkitProfile.lock
Sorry, but for now its a bit too hard for me to build a patch.
Assignee: hskupin → nobody
Status: ASSIGNED → NEW
This bug appears to be over three years old.  The error message given by both FF and TB is both misleading and incorrect.  
Surely the accessibility of the profile path does not need to be checked every time an attempt is made to lock the profile, just once at the beginning of the application before any attempts are made to lock the profile.
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
No longer blocks: 459991
Blocks: tomtom
Might it be possible to separate some of the concerns in this bug? Looking at the history of it, it seems even that even small bits of progress are stymied, probably because of the mesh of all the other issues.

Can some one with word-smith-ability propose an acceptable message for the alert?

Someone else could implement the change to make a new alert message come up, no?

Should there be different exceptions getting thrown here? It seems as though "I have a directory or file and cannot lock it" would throw a different exception than "I cannot find the directory or file". Perhaps if the lock fails to happen, code can check which factor is causing the problem and throw a more informative exception.
As a matter of fact, this error does not say true. It should be changed to "Error: Profile folder was not found. Please use profile manager to find correct path. [Profile Manager] [Create new default profile] [Cancel]"
This bug appears to be nearly five years old. The error message is both misleading and incorrect.
Attached patch WIP v1 (obsolete) — — Splinter Review 
I'd like to know what benjamin thinks about this approach (same of bug 531532)
Attachment #287885 - Attachment is obsolete: true
Attachment #416081 - Flags: review?(benjamin)
The patch works but if I click on "Ok" (I want to create the missing profile folder), firefox crashes between the first and the second printf. I don't know why.

Step to reproduce (comment 12):
1. Create a new profile, say called test2:
   firefox.exe -p
   Create Profile
   test2

2. Exit firefox.

3. Delete test2 profile directory manually.

4. Start firefox.exe

5. Click on "Ok"

Firefox crashes after creating the profile folder.
Attachment #416081 - Attachment is obsolete: true
Attachment #416081 - Flags: review?(benjamin)
Attached patch WIP v2 (obsolete) — — Splinter Review 
This works but I don't think the dialog box is completly correct.
It should answer to the user where is the new profile folder (in case of -p argument)
Attachment #416294 - Flags: review?(benjamin)
It would be very great if there were improvements made in the profile selection system.
If the profile is not found the user should get a popup with these possibilities.

-Search for the profile path
-choose an alternative profile manually
-automatically choose another profile if 1st profile is not available

Mfg Urmel
Also affects recent seamonkey:
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100108 SeaMonkey/2.1a1pre
Has someone tested the patch from Gabriele Best [:Gabri] (2009-12-05)? Is it already included in a firefox, seamonkey version, but not seam2.1a1? If not, is someone already going through "Life Cycle of a Patch" (http://www-archive.mozilla.org/hacking/life-cycle.html)?
As you can see at the top of the page, the patch is marked "gabri.best: review? (benjamin)".  That means it's up to the stage "Ask a module owner or peer for the module in question explicitly for a review".
Comment on attachment 416294 [details] [diff] [review]
WIP v2

Users don't have enough context to answer this question. In any case, I'm trying to remove the profile manager in bug 214675, so I think this problem will be mostly moot.
Attachment #416294 - Flags: review?(benjamin) → review-
Blocks: 539524
No longer blocks: 539524
For what it's worth, I believe this bug still exists on the latest Thundebird (ver 3.0.4).  I installed TB on XP Pro client computers (SP3 with latest patches) at my wife's business with a Windows 2000 server and a network.  The profile folder was on a mapped drive (on the server) and we are intermittently getting the "Thunderbird is already running..." message on one of the clients.  Was the initialization of the mapped drives done on this version? It seems that sometimes we get the message and sometimes we don't.  (We also have NOD32 anti-virus running on its start-up scan so I don't know if that is a contributing cause.)  Out of 3 reboots, I got the error once; it's not consistent.
Wow, a five-and-a-half-year-old bug that's still not fixed? (Yes, I've seen it intermittently for years, and I'm seeing it in ver 3.x.) Is it a hard one to fix, or just a low priority?
Bug exists in firefox=3.6.8 on ubuntu lucid. I setup my account (which unfortunately required a different username=bar) on a new box by restoring from a backup on my current one (on which my username=foo). I got the error, which confused me until I remembered to fix profiles.ini on the new box (sed -sie 's|/home/foo|/home/bar|g)
Six years. Is there any interest in fixing this? The error message is both
misleading and incorrect. Is it a hard one to fix, or just a low priority?
Bug still exists with Firefox 3.6.12 and Thunderbird 3.1.6 (under Linux Mint 10 (Gnome 64-bit).
The buggy message occurs very easily if the profiles are stored on a mounted drive and I forgot to mount it after boot.
What _really_ is necessary is to change the message text. It should point the user into the right direction, in this case something with "profile not found"
Is it so hard to fix? If not, please rise its priority!
Yes, I still am interested.

1) Without the ability to switch profiles, tracking down configuration issues or bugs in addons is rather difficult.
2) Without the ability to run two or three firefox instances with different profiles, comparing the behaviour of different firefox versions is nearly impossible.

Fixing the message text is one thing, but in my opinion it's only a minor step.
I think it is rather necessary to clean up the whole profile and version handling of firefox.
If firefox can find out that there's another instance already running, how about finding out which version and which profile it's running and presenting options accordingly?
(In reply to comment #100)
> 2) Without the ability to run two or three firefox instances with different
> profiles, comparing the behaviour of different firefox versions is nearly
> impossible.
But it's possible... Just not from GUI, that's what -no-remote switch is for.
Since my bug report got marked as a duplicate I am transferring what I consider usefull info here.

This isn't just a simple bug, it is an improper way to detect running instances of an application on the Windows platform -- code for detection should be made platform specific and proper code should be added.

On Windows platform, the usual way to detect another instance of a running application is to CreateMutex() (global, named) upon startup. If that fails
with GetLastError() == ERROR_ALREADY_EXISTS, then the application is already
running. Only then you should show "Application XYZ is already running" message.

Second part of the solution when the profile is really inaccessible for whatever reason is to let the user know that the profile is (temporarily) inaccessible, and perhaps offer an option to retry after user corrects the condition (i.e. by mounting the drive) or to create a new profile elsewhere.
(In reply to comment #106)
> Since my bug report got marked as a duplicate I am transferring what I consider
> usefull info here.
> 
> This isn't just a simple bug, it is an improper way to detect running instances
> of an application on the Windows platform -- code for detection should be made
> platform specific and proper code should be added.
> 
> On Windows platform, the usual way to detect another instance of a running
> application is to CreateMutex() (global, named) upon startup. If that fails
> with GetLastError() == ERROR_ALREADY_EXISTS, then the application is already
> running. Only then you should show "Application XYZ is already running"
> message.
CreateMutex, etc is already used and support for having multiple profiles is the reason using CreateMutex isn't sufficient to fix this.
(In reply to comment #107)
> CreateMutex, etc is already used and support for having multiple profiles is
> the reason using CreateMutex isn't sufficient to fix this.

CreateMutex() should be sufficient to prevent both Firefox and Thunderbird from showing "Application is already running" when they cannot access the profile. 

What they should show when they really cannot access the profile is open for debate.
I should have stated "use multiple profiles". When not using -no-remote and the app is already running the instance that is launched hands off urls to the running instance. When running multiple profiles using -no-remote it doesn't set up the mutex and there currently isn't a method to reliably detect this case. Since this is per user and a different user can technically use a different user's profile just using a mutex isn't sufficient though that is an edgecase.
If I launch Firefox using a desktop icon created by setup (i.e. with no special command line switches) and if its only profile specified by absolute path (see below) is not accessible (due to the volume not being mounted for example) it will tell me that it is already running which is quite obviously wrong.

-- snip from profiles.ini --
[Profile0]
Name=default
IsRelative=0
Path=M:\DATA\FF
-- snip from profiles.ini --

Note that I am not even touching multi-profile and multi-user issues here and I still have the same problem -- application which is unable to discern whether it is already running or not.
It has taken over 6 years to fix an error message that everyone agrees is incorrect (in both Firefox and Thunderbird), and that has been reported as a bug no less than 50 times. What's the holdup?

Incidentally, another possible cause is that the file permissions on the profile folder are wrong, or it is mounted read-only.
"firefox is already running" also shows up when the profile is in place, but the drive where it's located is full.
Why is this ticket "New" after 6 years?

Suggestion:
Yes, it would be a great help to change the text of the error message to 
 "Your user profile data at <path> can't be read. 
 (This may happen when another instance of the program 
  is already running, or the path is wrong.)"

Last weekend when I helped someone fix his computer with the "already-running"-message, I spent half an hour with updating Thunderbird, rebooting the PC, checking the task manager. Just by instinct I finally examined the profiles.ini and discovered that the profile directory had been moved.
(In reply to Dirk Schoettler from comment #115)
> Suggestion:
> Yes, it would be a great help to change the text of the error message

Yes, time to get this changed, and do it the easy way.  Why not just change the string so it covers all cases?

I suggest
"Your user profile data cannot be read. 
This can happen when Thunderbird is already running or the profile cannot be found."

Simple and short.
Simple and short... I agree   :-)
I suggest

"<product> can't work with the configured user profile at <path> because of <reason>"

Note that "reason" can be "drive full", among other things. Since <product> probably does know the detailed reason from the specific system code, why not to tell it to the user. Telling <path> will also help to look into the right place, rather than begin research "where does firefox keep its profile".
@Vadim Rapp: +1
Vadim, Tom, a detailed error message helps a lot to cure a problem, yes.

Though, if its too complicated for the programmer to distinguish between the causes (directory not found, file not found, file locked, file corrupt...) then I would definitively prefer a simple & early fix! 

IMHO a sophisticated solution here is not worth waiting some more years...
A detailed message has been tried, but 6 years later there is still no patch.

A static message would be perfectly adequate if it were correct.  Now, can somebody please just submit a patch?
(In reply to guanxi from comment #10)
> Many bugs duped to this one see behavior similar to the following.  You can
> also find several posts in Mozillazine's forums if you search for the error
> message below.
> 
> Firefox 1.5:
> 
> 1)  Firefox not running
> 
> 2)  Rename profile folder
> 
> 3)  Start Firefox
> 
> 4)  Displays window:
> 
> "Firefox is already running, but not responding. To open a new window, you
> must
> first close the existing firefox process, or restart your system"

Still a major issue on latest Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1.
Even re-installing Firefox doesn't make it able to start after profile deletion.
Bug 237127 added in a profile missing dialog. I believe now it is just a matter of hooking up to this particular error case.
ARGH. Bug 237128
This patch adds a check for the existence of the profile directory in three places.

This handles:

1. Directory not available when there is only one profile.
2. Directory not available when explicitly specified on the command line
3. Directory not available when the profile is selected in the profile dialog.

In all cases, I added this check before the lock dialog was about to display, so this will not affect startup.
Assignee: nobody → mozilla
Attachment #416294 - Attachment is obsolete: true
Attachment #608341 - Flags: review?(benjamin)
bsmedberg, any chance you'll have a chance to look at this?

I'd like to try to get it into the next build since it's causing issues for some work I'm doing.
bsmedberg said it's on his list, but not at the top of the queue. He's ok with Dolske or Mossop reviewing this instead.
Comment on attachment 608341 [details] [diff] [review]
Add directory check in three places

ok, this seems to be bypassing all the hot codepaths (where we don't want to be calling Exists() if we can help it). So I think that's ok. I wonder if we should be providing the actual directory name in the dialog... oh well, this is good enough for now.
Attachment #608341 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
This needs approval if you want it landed for Firefox 14.  Otherwise, we can land it on the Birch branch.
Keywords: checkin-needed
Comment on attachment 608341 [details] [diff] [review]
Add directory check in three places

Review of attachment 608341 [details] [diff] [review]:
-----------------------------------------------------------------

Requesting approval for mozilla-central.

This is desktop only and has quite a few dupes.

We have an app that would like to have it because it will help us diagnose some profile problems we're having.
Attachment #608341 - Flags: approval-mozilla-central?
Attachment #608341 - Flags: approval-mozilla-central? → approval-mozilla-central+
https://hg.mozilla.org/mozilla-central/rev/d665f2ad8a78
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/mozilla-central/rev/d665f2ad8a78#l1.16
How do you expect this to work since gPromptService was replaced with Services.prompt in Bug 714606? Did anyone bother to test this patch?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> Did anyone bother to test this patch?

Yes. Unfortunately it was tested on March 22.

And because the patch was self contained, it applied clean.

I'll post a new patch for that part.
[Approval Request Comment]
This patch crossed with 714606 which was the removal of gPromptService
As a result, part of the patch fails.
If declined, if a user hits this scenario, they will get no prompt at all
Little to no risk patch.
Attachment #619914 - Flags: review?(dtownsend+bugmail)
Attachment #619914 - Flags: approval-mozilla-aurora?
Attachment #619914 - Flags: review?(dtownsend+bugmail) → review+
Attachment #619914 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/ec8dbe9d9a32
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
So now the user knows that "Your firefox profile cannot be loaded. It may be missing or inaccessible". But how does this solve the problem? Firefox is still not able to start. Wouldn't be possible to automatically create a default profile and also notify the user about this?
> Wouldn't be possible to automatically create a default profile and also notify the user about this?

That's really not feasible. There are many reasons for this error. Network drive no longer there, USB drive no longer there, read error on hard drive, data corruption, etc. etc.

If you want to continue this discussion, please open another bug. That discussion does not belong here.
(In reply to Paul Silaghi [QA] from comment #140)
> So now the user knows that "Your firefox profile cannot be loaded. It may be
> missing or inaccessible". But how does this solve the problem? 

The user will use the information from the error message to troubleshoot the problem, as with any other problem. Specifically, he will go to the location of his user profile and check if it's really missing or inaccessible.

The only wish here is that the error message might assist in this by telling the expected location of the profile - since by all means the user will need it, and it's probably very easy to insert in the message.
Blocks: 752822
(In reply to Vadim Rapp from comment #142)
> The only wish here is that the error message might assist in this by telling
> the expected location of the profile - since by all means the user will need
> it, and it's probably very easy to insert in the message.

Sounds good to indicate the location of the profile. New bug 752822 filed.
No longer blocks: 752822
Marking this as verified fixed on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120507 Firefox/14.0a2
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120507 Firefox/14.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120507 Firefox/14.0a2
Status: RESOLVED → VERIFIED
status-firefox14: fixed → verified
(In reply to Paul Silaghi [QA] from comment #145 and Michael Kaply from comment #143)
> Marking this as verified fixed on:
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120507 Firefox/14.0a2...

Thanks, but what about Thunderbird?  (See comment #0.)
This is also verified fixed on Thunderbird 14.0a2 (2012-05-07) on Win 7 64-bit, Ubuntu 11.10 and Mac OS X 10.6. "Your Thunderbird profile cannot be loaded. It may be missing or inaccessible" error message is displayed.
Depends on: 766494
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: