# fix\(desktop\): probe Firefox's fcntl lock so a running macOS Firefox is detected · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/commit/c44e9590f68d17478f581e09585052513672701b)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

Requested revision: c44e9590f68d17478f581e09585052513672701b

Requested commit: c44e9590f68d17478f581e09585052513672701b

Commit: c44e9590f68d17478f581e09585052513672701b

Tree: a43818efcaa39a7cea14e89aa03d7a0e8914fa4c

Author: Julius Marminge

Committer: Julius Marminge

## Message

```
fix(desktop): probe Firefox's fcntl lock so a running macOS Firefox is detected

Follow-ups to the leftover-lock fix. On macOS a running Firefox writes nothing
but an empty `.parentlock` held with an fcntl lock — no symlink, no pid — so
reading only the Linux `lock` symlink missed it entirely and offered imports
from a live, mid-write database. Node exposes no fcntl, so a throwaway
`python3` child tries a non-blocking F_SETLK and reports whether it blocks;
any failure to get a clean answer counts as held, so a probe problem can
never unlock a live profile. The Linux symlink still short-circuits first.

The symlink's owner half is honoured too: a non-loopback address is a shared
profile locked from another machine, whose pid cannot be probed here, so it
stays held. Also drops a Safari paragraph from `entryExists`' doc that
described `databaseFileExists`' concern, not this helper's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

```

## Parents

- [266ec2a604bd1fbfdd522177b5f392ddc631d467](https://git.cafe/pingdotgg/t3code/commit/266ec2a604bd1fbfdd522177b5f392ddc631d467?format=markdown)

[Source at this commit](https://git.cafe/pingdotgg/t3code/tree/c44e9590f68d17478f581e09585052513672701b?format=markdown)