Open Bug 726759 Opened 8 years ago Updated 2 years ago
Profile manager assumes Windows profile is locked if parent
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 Build ID: 20120207235853 Steps to reproduce: Downloaded http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1328687933/firefox-13.0a1.en-US.win32.zip (built from http://hg.mozilla.org/integration/mozilla-inbound/rev/36b986ef4b5b )and unzipped to a desktop directory. Started Profile Manager, created new profile, and launched the unzipped build using that profile. Exit firefox and check the profile directory for parent.lock file. Actual results: parent.lock file remained in profile directory after shut down, locking the profile. Expected results: parent.lock should be deleted at shutdown, unlocking the profile.
I don't know if this is intended as part of the 'silent updates', but it appears to be a regression in that on 10.0.1 on WinXP SP3 the parent.lock file is deleted on close of the browser. Saw this mentioned a couple of days ago, and on win32 m-c on Win7 x64 builds using the 'installer - .exe' builds - the parent.lock file does NOT go away on close, but I can restart the browser without getting any 'browser is already running' messages. Adding regression/window wanted for now.
I changed the behaviour of profile locks in bug 294260 to be able to detect startup crashes. The timestamp of the existing parent.lock file during startup is compared to a preference value to see if the last startup was successful. bomfog, did the existence of parent.lock cause a problem for you? Did you see the profile locked dialog? (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #1) > but I can restart the browser without getting any 'browser is > already running' messages. Jim, my understanding is that you didn't get the profile locked dialog at any point? Is this correct?
Hardware: x86 → All
(In reply to Matthew N. [:MattN] from comment #2) > bomfog, did the existence of parent.lock cause a problem for you? Did you > see the profile locked dialog? Using Profile Manager app, there's a dialogue saying (paraphrased) "the profile appears to be in use - start anyway and risk corruption?". I say "sure", and firefox starts without further problem. Haven't tried non-Profile Manager start-up.
Last good changeset: http://hg.mozilla.org/integration/mozilla-inbound/rev/d6b8a8bedb49 First bad changeset: http://hg.mozilla.org/integration/mozilla-inbound/rev/36b986ef4b5b
OK, I'll investigate. Thanks for the report.
Assignee: nobody → mnoorenberghe+bmo
Status: NEW → ASSIGNED
> Jim, my understanding is that you didn't get the profile locked dialog at > any point? Is this correct? Correct, I did not see any warnings about 'profile in use'... but the file: parent.lock does indeed hang around on close. To be clear its not causing me any issues due to its presence.
Assignee: mnoorenberghe+bmo → nobody
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
QA Contact: untriaged → startup
Hardware: x86 → All
Assignee: nobody → mnoorenberghe+bmo
This is something that should be fixed in the external Profile Manager application. The existence of parent.lock is no longer sufficient to know if a profile is locked. Instead the code should try to open the lock file (ie. with CreateFileW) and if it succeeds then then the application is not running since it has dwShareMode = 0 (no sharing). If the profile is locked then I think you get ERROR_SHARING_VIOLATION. https://mxr.mozilla.org/mozilla-central/source/profile/dirserviceprovider/src/nsProfileLock.cpp?rev=bcdc5493e6a1#612 http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Assignee: mnoorenberghe+bmo → nobody
Status: ASSIGNED → NEW
Component: Startup and Profile System → ProfileManager
Product: Toolkit → Testing
QA Contact: startup → profilemanager
Summary: parent.lock not deleted from profile when firefox closes → Profile manager assumes Windows profile is locked if parent.lock exists
Works for me on Nightly. Or Nightlies are not affected by this bug?
I can (re)start without deleting parent.lock file, on Windows 7 and XP. (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #1) > Saw this mentioned a couple of days ago, and on win32 m-c on Win7 x64 builds > using the 'installer - .exe' builds - the parent.lock file does NOT go away > on close, but I can restart the browser without getting any 'browser is > already running' messages. bomfog use Vista and have problem. so seems to be problem on only Vista.
(In reply to pal-moz from comment #9) > bomfog use Vista and have problem. > so seems to be problem on only Vista. Same result on win7 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/13.0a1 Firefox/13.0a1 Profile Manager v1.0 Build/201111041528, XULRunner/7.0.1 Note: Restart "works" with or without Prof. Man., and without (at least manually) deleting the .lock file. The issue, I think, is Prof Man using a faulty/outdated method of detecting profile in use, and throwing up an unnecessary dialogue.
Confirming the problem on Windows 7.
I can confirm for WinXP. The window does pop up. I can't start FF13b2 unless I go into the profile and delete parent.lock
(In reply to email@example.com from comment #12) > I can confirm for WinXP. > > The window does pop up. I can't start FF13b2 unless I go into the profile > and delete parent.lock That would FF13b2 portable. FF13b2 installed in Win7 64bit is running fine.
(In reply to firstname.lastname@example.org from comment #13) > (In reply to email@example.com from comment #12) > > I can confirm for WinXP. > > > > The window does pop up. I can't start FF13b2 unless I go into the profile > > and delete parent.lock > > That would FF13b2 portable. > > FF13b2 installed in Win7 64bit is running fine. The problem may have been with the portable version from portableappz.com The version from portableapps.com is fine both in WinXP and Win7 64.
(In reply to Matthew N. [:MattN] from comment #2) > I changed the behaviour of profile locks in bug 294260 to be able to detect > startup crashes. The timestamp of the existing parent.lock file during > startup is compared to a preference value to see if the last startup was > successful. Matthew, that's exactly what the problem is: You changed some behaviour that had worked for years before. It had been possible to check whether the profile is used by testing the parent.lock existence. Now any and every external application have to be changed. So the general test (working for FF 13, FF 12 and lower on Windows and Linuxes) shall be: - no parent.lock or parent.lock readable -> the profile is not used; - otherwise -> the profile is used? Couldn't you use another file to store the timestamp? E.g. you could rename parent.lock on exit to keep the timestamp for your new functionality while keeping the old behaviour? This would be very appreciated.
(In reply to Jan Janousek from comment #15) > (In reply to Matthew N. [:MattN] from comment #2) > > I changed the behaviour of profile locks in bug 294260 to be able to detect > > startup crashes. The timestamp of the existing parent.lock file during > > startup is compared to a preference value to see if the last startup was > > successful. > > Matthew, that's exactly what the problem is: You changed some behaviour that > had worked for years before. It had been possible to check whether the > profile is used by testing the parent.lock existence. Now any and every > external application have to be changed. Checking the existence alone was not enough before either since the lock would stay around if the application crashed. The built-in profile manager did the correct thing and tried to acquire a lock on the profile to know whether it is in-use. There is code which can detect a stale lock (ie. in the case of a crash). > So the general test (working for FF 13, FF 12 and lower on Windows and > Linuxes) shall be: > - no parent.lock or parent.lock readable -> the profile is not used; > - otherwise -> the profile is used? If possible, it's best to use the profile lock class and try to acquire the profile lock and see if it succeeds. Otherwise, you should use fcntl and check the symlink on Linux. See the Lock function and it's helpers in https://mxr.mozilla.org/mozilla-central/source/profile/dirserviceprovider/src/nsProfileLock.cpp#434 > Couldn't you use another file to store the timestamp? E.g. you could rename > parent.lock on exit to keep the timestamp for your new functionality while > keeping the old behaviour? This would be very appreciated. I would have liked to not use the profile lock in this way but the alternatives that we found would slow down either startup or shutdown in the normal case which we obviously don't want to do.
Here's a quick fix that tries to delete the lock on Windows if it exists. This will fail when the profile is in use because the application opens the file for exclusive use. The side-effect of this patch is that startup crashes will not be detected when the profile manager tool is used since it relies on the timestamp of the lock file. A proper solution would use js-ctypes to call CreateFileW to open the file for writing instead of deleting it. We could also use the new OS.File JS File.open API to do this more easily in versions where it's available.
Attachment #646432 - Flags: review?(jgriffin)
In Vista x64, even though Profile Manager shows every profile that I've recently used as locked, when selecting a profile & starting Fx 13, 14 from Profile Mgr, so far I haven't had problems (no corruptions or notices) when starting Fx from a * shortcut,* using a profile that profile manager reported locked. BUT... profile manager showing profiles are locked - when they aren't - & the warning * profile manager * shows about "risk of corruption if you continue" when starting Fx 13,14 w/ a "locked" profile is confusing for avg users, at best, & likely causes a lot of wasted time (as did for me) trying to figure out why it's showing locked profiles. The other changes mentioned in Profile Mgr may be necessary, but the false locked status & erroneous dire warnings are unacceptable.
Seems at very least, until a fix is implemented, an explanation of locked profile error should be added to the doc on MDN & probably a readme / known issues file included w/ the Profile Mgr download.
Comment on attachment 646432 [details] [diff] [review] v.1 Quick fix to attempt to delete the lock on Windows I'd rather not break crash detection. Your alternative of using ctypes and CreateFileW would be much preferred. Are you comfortable attempting that?
Attachment #646432 - Flags: review?(jgriffin) → review-
I use FF 14.0.1 on a Vista basic laptop. On this windows user I have 3 profiles A the default that opens in a new screen, B that opens in a new tab and C with all default options that I don't use often. The external profile manager reported that A and B were locked. I opened B (ignoring as usual the error message) and clicked on the link to a bug change report received with TB, the result was 2 (two) occurrences of screens with the same bug (292385) report opened with the A profile (my personal (3rd line) bar is not the same as B) : this is very strange ! I closed the 2 A screens and retried : same result. I have then done a google search on "firefox locked profile" looked at some results they opened with B as required. After closure of B FF no more occurrence of applications or tasks named FF, only a "Mozilla maintenance" service in stop state. Then I searched for parent.lock files in my whole PC and renamed all (4) occurrences to parent2.lock. No profiles were reported as locked. I opened B and now the bug report opens as a tab in it (B) as required. So the remaining parent.lock files seem more pernicious that previously reported. Is it possible that FF seeing a parent.lock in the default profile thinks that it is open and choose it to open the link ? ( but why twice ? I am not a code developer). Do I need to open a new bug or is this comment here sufficient ?
I've used the external )not Fx native) profile manager for ? couple yrs, in Vista x64. Was only recently (maybe since Fx 12 - 15?) that the warnings about "profile x,y,z appear to be locked... starting them may ...damage..." This now occurs on creating every new profile, or installing new Fx & selecting profile it should use; NO profiles are in use at time of msg. It now often shows > 1 profile in list as "locked", but I click thru warning (after reading others experiences) w/ no ill effect. Yet, to new users, would be quite disturbing - likely cause them to ditch this Profile Mgr.
Should add, now using latest ver Profile Manager could FIND - updated Nov 11, 2011. Every profile I've used for any Fx ver, in recent past, is now shown as locked - 4 or 5 profiles. Of course, they're not locked.
Is this alive?
(In reply to bomfog from comment #10) > (In reply to pal-moz from comment #9) > Note: Restart "works" with or without Prof. Man., and without (at least > manually) deleting the .lock file. The issue, I think, is Prof Man using a > faulty/outdated method of detecting profile in use, and throwing up an > unnecessary dialogue. I agree the issue is with the external Profile Manager app being outdated. When running Firefox with the internal manager no error is received and functions as it should. When using the external manager it will result in an error. With the persistence of the parent.lock file now being left behind this hinders the external Profile manager useless unless you constantly ignore the error and proceed. I am still indifferent on the external tool versus using the internal + FEBE. The only benefit I see for the external is allowing the easy swapping of various Firefox versions for a single profile.
You need to log in before you can comment on or make changes to this bug.