Closed
Bug 597060
Opened 14 years ago
Closed 14 years ago
ProfileManager should have a notion of locked profiles
Categories
(Testing Graveyard :: ProfileManager, defect)
Testing Graveyard
ProfileManager
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: k0scist, Unassigned)
References
Details
currently, ProfileManager is unaware if a profile is in-use (locked). It needs to know this
Reporter | ||
Comment 1•14 years ago
|
||
ProfileManager should probably display this data somehow (maybe with a little locked icon). In linux, at least the lock is in the form of a symlink with a (non-existant) target of 127.0.0.1:+PID Displaying the PID in the properties is probably also a good idea, maybe even with options to kill it, etc.
Comment 2•14 years ago
|
||
On windows, this lock takes the form of a 0-byte, open, locked file called 'parent.lock'.
Reporter | ||
Comment 3•14 years ago
|
||
(In reply to comment #2) > On windows, this lock takes the form of a 0-byte, open, locked file called > 'parent.lock'. Not very helpful for process IDs. I assume Mac is the same as linux. So since we can't support windows for displaying the PID, just note that its locked for now and work on the more robust solution in the future.
Comment 4•14 years ago
|
||
Apparently on mac, just to confuse things, the file is either .parentlock or parent.lock. See: http://mxr.mozilla.org/mozilla-central/source/profile/dirserviceprovider/src/nsProfileLock.cpp#438
Comment 5•14 years ago
|
||
Looking at existing toolkit code, http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/content/profileSelection.js#120 it seems that the way to test for lock is to use nsIProfileLock to attempt to lock the profile. If an exception is thrown, it means it is already locked.
Comment 6•14 years ago
|
||
According to the patch in bug 214675, nsIProfileLock is going away once they remove the 'old' profile manager, but the actual locking mechanism itself in nsProfileLock remains. We should clarify with dev before making any changes.
Comment 7•14 years ago
|
||
ProfileManager now detects locked profiles, and displays locked status in the UI. Preventing ProfileManager from launching or doing other operations on locked profiles is covered by other bugs.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 8•14 years ago
|
||
Reopening this, as lock detection doesn't work on Mac. The issue is that on Mac, locking is done via fcntl, and there is no scriptable interface for this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 9•14 years ago
|
||
Dave, Benjamin, we'd like the new Profile Manager to be able to detect locked profiles, for a number of use cases. The code for locking profiles in nsProfileLock is rather complicated, and in some cases involves fcntl, for which there is no scriptable interface. In order to support locked profile detection, it seems we have a couple of choices: * implement a new interface to nsProfileLock that Profile Manager could call (since existing nsToolkitProfileServce.cpp seems to be going away) * implement an interface for fcntl Any suggestions or ideas?
Comment 10•14 years ago
|
||
(In reply to comment #9) > Dave, Benjamin, we'd like the new Profile Manager to be able to detect locked > profiles, for a number of use cases. The code for locking profiles in > nsProfileLock is rather complicated, and in some cases involves fcntl, for > which there is no scriptable interface. > > In order to support locked profile detection, it seems we have a couple of > choices: > * implement a new interface to nsProfileLock that Profile Manager could call > (since existing nsToolkitProfileServce.cpp seems to be going away) > * implement an interface for fcntl > > Any suggestions or ideas? Can we get to fcntl through ctypes?
Comment 11•14 years ago
|
||
> Can we get to fcntl through ctypes?
Good idea, I'll give it a shot.
Comment 12•14 years ago
|
||
What is the problem you're actually trying to solve? Determining whether a profile is locked? The only way we have of doing that reliably right now is to try and lock it and see whether that succeeded.I really don't want to duplicate the logic in another piece of code... XRE_LockProfileDirectory is the current API which we use, and you get back a profile lock object.But since you can't pass a profile lock between processes, I'm not sure that this should be fixed at all.
Reporter | ||
Comment 13•14 years ago
|
||
(In reply to comment #12) > What is the problem you're actually trying to solve? Determining whether a > profile is locked? The only way we have of doing that reliably right now is to > try and lock it and see whether that succeeded.I really don't want to duplicate > the logic in another piece of code... XRE_LockProfileDirectory is the current > API which we use, and you get back a profile lock object.But since you can't > pass a profile lock between processes, I'm not sure that this should be fixed > at all. If we don't do this, then ProfileManager won't work correctly on Mac -- you will go to launch a locked profile and it will silently fail. We can make it fail less silently (I think) or just live with this failure, but unless we can detect locked profiles, we can't launch reliably.
Comment 14•14 years ago
|
||
> What is the problem you're actually trying to solve? Determining whether a
> profile is locked?
Yes. Ideally we'd try to lock the profile, and if it succeeded, we'd know the profile was not locked, and we'd immediately unlock it. Do you not think this approach is workable?
Comment 15•14 years ago
|
||
Why would it silently fail? Won't you get the normal "Firefox is already running..." dialog? We could certainly add a scriptable .lockProfileDirectory API somewhere convenient. I'm not sure it's worth the complexity, though. Can we just punt on it, and if you try to launch a locked profile it shows the normal dialog?
Comment 16•14 years ago
|
||
Another reason why it would be nice to know whether a profile is locked is that currently, on Windows at least, attempting to copy/backup a locked profile dies, as the OS can't copy the locked file. This happens because we attempt to copy the entire profile dir in one call. We could fix this by recursively copying files instead, but this would be a bit slower. I can access fcntl via ctypes as Dave suggested, so I could make a lockProfile function in script. But I understand the concern about reproducing this big blob of code. If you still think it's just best to skip this, we'll do that.
Comment 17•14 years ago
|
||
I've given profile manager the ability to detect locked profiles, so we can warn the user if he's about to delete/copy/backup/restore a locked profile, since this will likely cause problems. For Windows, this is as easy as looking for a specific file; for Mac and Linux it involves checking for a fcntl lock via ctypes.jsm, and failing that, checking for a symlink, which if it exists, is checked for staleness (using more ctypes). This seems reasonably clean and works in all the cases I could test; the one exception is it may fail to detect profile lock from Firefox 1.5 and older.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Whiteboard: [blocker-1.0]
Updated•6 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•