Closed Bug 597060 Opened 14 years ago Closed 14 years ago

ProfileManager should have a notion of locked profiles

Categories

(Testing Graveyard :: ProfileManager, defect)

defect
Not set
normal

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
Blocks: 597073
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.
On windows, this lock takes the form of a 0-byte, open, locked file called 'parent.lock'.
(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.
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
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.
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.
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
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 → ---
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?
(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?
> Can we get to fcntl through ctypes?

Good idea, I'll give it a shot.
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.
(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.
> 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?
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?
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.
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 ago14 years ago
Resolution: --- → FIXED
Whiteboard: [blocker-1.0]
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.