On 12/6/24 6:20 PM, Tim via users wrote:
I think in Firefox's case, it's more of some kind of flag that it uses only for itself, rather than anything else (not preventing something else deleting it, for instance). From my programming in binary days (when *you* are the compiler) it's like storing things in registers. However, I also wonder if this is the best way of doing it. Storing transitory data for an application that may well crash (browsers aren't known for stability and good programming practices) as any kind of file on disk is asking for trouble. Unless, at start up they look for these things and do clean-up housekeeping. Which, rather obviously, they don't when you're able to find such leftovers after the fact. Permanent, on-going, data stored that way is another matter. Or, where one program has to communicate data with another. But that should probably some volatile storage, instead. And there are other systems for piping data between apps than storing some kind of file (I'm lumping symlinks in with that, here). I suppose the big question is how much of a problem are they? On a storage system with limited nodes and lots of applications that might be doing the same thing, perhaps. On a user's system who never does fresh installs, and has being doing over-the-top updates for the last 15 years, perhaps even more so. Although these will hardly be the only leftover files that accumulate in the background.
There's nothing accumulating here. The lock file is checked at application startup. If it's still valid, then the new process will not start, probably passing information to the existing process. If it's not valid, then the old lock is deleted and a new one created. Standard practice, just using a symlink instead of a file.
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
