Can anyone explain what the purposes of the .parentlock file and the lock symbolic link that Firefox uses to indicate when a profile is in use?

Obviously I know they're used to mark that the profile is in use, but only one file is used for the same purpose on Windows (parent.lock) and Mac OS X (.parentlock). So what I want to know is why does Linux use two files and what purpose does each of the files serve?

I've looked and looked and looked some more for this information and the question has gone unanswered (as yet) on the Firefox support forums.

~/.mozilla/firefox/lpih4bes.default/.parentlock

In the windows version, it is called "parent.lock".
This file tells firefox that the profile is already in use, so it is also known as the profile lock file.

Explore Mozillazine

FWIW, both options can be compiled in or out (on *nix), if you build your own Firefox.

Doesn't really make sense that both "parental controls" (whatever that is) and "profile sharing" (implying that each instance of FF can not use the same profile simultaneously) would use the same lock file. Weird, though I hadn't looked this far into these features.

Yes, I know. As demonstrated by my mentioning this in my original post.

What I want to know is, why is there both a .parentlock file and a symbolic link called lock? Why does Linux use two files to achieve what is done using one file on Windows and Mac OS X?

I know from experience that if one encounters the problem of Firefox claiming that the profile is in use when you know for certain that it isn't, the problem can be cured by deleting .parentlock. (I have seen this problem when no lock file exists.) What puzzles me about this is that .parentlock always seems to exist and is always zero length regardless of whether Firefox is actually running:

With Firefox running:
Where 127.0.0.2 is the IP address of the machine the profile is in use on and the 3557 is the process ID of the Firefox process that's using the profile.

With Firefox not running:
So what I'm trying to understand is what that .parentlock file actually does.


Where do you get "parental controls" from?

"parental controls" is a build option that can be enabled or disabled. Here's a snippet from my Firefox build script:

I have no idea how one 'uses' this option in real life; I have never seen any mention in about:config or in my FF UI about it, so maybe it's usually disabled by default, on standard builds?

OK. What does that have to do with my original question?

The above is from your original question.
IMHO, it is logical to figure that a file called .parentlock and a build option called "Parental Controls" are related, and therefore I tried to provide come context that might help you deduce something about the .parentlock file.

If I was wrong, so be it. Disregard the information

Sasha

I see I'm not the only one to misunderstand the intent of the original post
~/.mozilla/firefox/lpih4bes.default/.parentlock
~/.mozilla/firefox/lpih4bes.default/lock -> 127.0.1.1:+22023

Sadly for the Morning Citrus Goddess, it is not normally associated with parental controls. Though that's a reasonable guess. It is called "parent" lock because it locks the parent process.

".parentlock" marks the profile in use

"lock" tells firefox where it is running and which PID it has.

I'm sure I have a simple picture of why this is useful, someplace, I'll go look.

Aside: the both of us answer a lot of these questions, and also have our own things to run. It helps us a great deal if you put the question you actually want answered close to the top of your post (in the first 128 characters, or, best, in the title). Otherwise you will find the first sentence ending in a question-mark gets emphasis.

1 members found this post helpful.

As promised - I checked: I know GrapefruiTgirl enjoys these details. Its not complete but should point you in the right direction.

Firefox reuses existing sessions in a multi-login environment if possible. The different files are because different OSs handle multi-login somewhat differently.

It's how a new instance tells an already running instance to open a URL that was given on the command line. OSX definitely uses a different procedure for this (OpenDoc events), and I don't know how
windows does it.

From reading the source code, linux grabs a lock with fcntl (on the .mozilla/etc/etc/lock file)and with the "ns-4.x compatible" symlink. OSX tries fcntl first, and only seems to fall back to the symlink if all else fails, and windows just does it's own thing. fcntl will fail to get a lock if the file is on an NFS share, presumably one without nfslock support.

The "ns-4.x compatible" symlink lets the program distinguish between a stale lock file created on the local machine (which can therefore be overwritten), and a lockfile created on a remote machine (which you may not want to overwrite), as it may still be valid.

For those that don't know, if your X environment is set up properly, and you do something like ssh with X forwarding enabled to a remote machine, then try to run firefox there, it'll actually spawn a new copy of your local firefox instance, rather than creating a copy of firefox on the remote machine and forwarding it back to you. Last time I did this it involved an NFS /home, so it's possible that's where it comes from. I would retest but Ubuntu doesn't set things up to do this by default (tcp disabled, etc), and I can't be bothered changing my local config.

I don't know for sure exactly what's supposed to happen if you do have NFS /home but for some reason you can't start a remote session of firefox - there's no provision for per-machine lock files. I guess it bails and causes frustration.

In general, you don't want it to be able to, otherwise the two processes writing to the one profile will stomp on each other and corrupt it. If you're using NFS /home, you use different profiles if you need to do that, and then you swear a lot when it breaks anyway because it's not very reliable over NFS.