It means that the link isn't pointing to a file at all – it is being "creatively used" for some other purpose, most likely to act as a lock file that one of your programs uses to detect an already-running instance of the same program. The link target is just some arbitrary value that only the program itself understands; it isn't meant to exist as a real file.
Normal files are read or written in at least two steps: first the program calls open()
and only then read()
, leaving an unwanted opportunity for other programs to run between the two operations.
Although most operating systems provide functions to coordinate exclusive access to an open file, often this is limited to local files only – e.g. the Linux flock() historically hasn't worked all that well via NFS (which used to be very relevant on traditional Unix environments where /home would be shared via NFS or AFS from a central server), and there's no support for locking at all in SFTP (SSHFS).
On the other hand, the symlink()
kernel function will create a link with a specified "target" value in just one step (i.e. it is an atomic operation), while the readlink()
function will read its target in one call as well – the program always gets either a complete link target or a "not found" error with nothing in between. This leads to some programs using symlinks to detect when their config directory is already being used by another instance even on a different machine.
("106.0.5249.119" is not an IP address – as the file name suggests, it is a version number of Chrome in the "major.minor.build.revision" format that is extremely common on Windows.
That said, you'll see the same trick being used by Firefox which does put IP addresses in its "lock" symlink targets.)