Unusual behavior of ln command

Help
1

I’ve noticed strange behavior with ln. I want to maintain one set of filters for thunderbird (betterbird), so I tried creating a hard link (symlinks aren’t recognized) from one account to the other, ie. ln acct1/msgFilterRules.dat acct2. It doesn’t complain, and a file is created, but I realized it actually, silently, created a copy not a link (they point to different inodes). OTOH, if I do, eg. ln acct1/msgFilterRules.dat ~/tmp and inspect the inode of that file, it is the same as the original file, as expected. In other words, ln seems to be failing without warning. What could be the reason for this?

As an aside, ls -il does not show the number of links, as once I’m sure it did. stat still works for this.

2

what type of filesystem are you operating on? i’m not able to repro that hardlink behavior on a recent nixos box w/ btrfs, for what that’s worth. is it possible that you’re hardlinking to a symlink that points into the nix store on a different fs?

~/t
❯ nixos-version &&
      findmnt --target . &&
      ln --version &&
      file (realpath (which ln)) &&
      rm -rf a{1,2} &&
      mkdir a{1,2} &&
      touch a1/f &&
      ln a1/f a2 &&
      ls -li a{1,2}/f

26.11.20261023.3ec6363 (Zokor)
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda3 btrfs  rw,relatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/
ln (GNU coreutils) 9.12
Packaged by https://nixos.org
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Parker and David MacKenzie.
/nix/store/cb987zkxvsv0490753ilrvn5yk7ylgxi-coreutils-9.12/bin/coreutils: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/pqyiidz5mi73wv5f91d48s9plcqyj5bz-glibc-2.44-57/lib/ld-linux-x86-64.so.2, BuildID[sha1]=1738d5304872ba11bccbf8478de1e736e51ebc27, for GNU/Linux 3.10.0, not stripped
6845145 -rw-r--r-- 2 rph rph 0 Oct 30 13:22 a1/f
6845145 -rw-r--r-- 2 rph rph 0 Oct 30 13:22 a2/f
3

I found the problem, which is thunderbird-related. If I edit a filter in either account, it apparently simply overwrites the file rather than opening and editing it, so it is no longer linked to the other. It doesn’t look like syncing the filters this way will work.

Thanks.