Inconsistent reporting of `st_nlink`

[allisonkarlitskaya]

1. Enable fuse-overlayfs for your container config:

$ cat ~/.config/containers/storage.conf 
[storage]
driver="overlay"

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

2. podman run -it --rm fedora
   In this container image the /usr/share/crypto-policies/DEFAULT/bind.txt and /usr/share/crypto-policies/back-ends/DEFAULT/bind.config files are hardlinked.

3. Run this command:

# stat /usr/share/crypto-policies/DEFAULT/bind.txt
...
Device: 0,125	Inode: 50057153    Links: 1
...

Note the device and inode, and the fact that Links: 1.

4. Run this command:

# stat /usr/share/crypto-policies/back-ends/DEFAULT/bind.config 
...
Device: 0,125	Inode: 50057153    Links: 2
...

Note that this is the same inode, on the same device, but somehow it has Links: 2 now.

5. Run this command (which is the same as the first command):

# stat /usr/share/crypto-policies/DEFAULT/bind.txt 
...
Device: 0,125	Inode: 50057153    Links: 2
...

And now note that Links: 2 as well when accessing the file through the original filename (which used to report Links: 1 in step 3).

The only think I can think of is that fuse-overlayfs reports st_nlink as 1 until it "sees" the second hardlink to the file, at which point it updates its opinion to st_nlink being 2, and persists that change in some kind of a cache.

Maybe it's doing that to avoid leaking outside information into the container? ie: maybe there are extra hardlinks that the container should not know about?

Either way, this is causing problems with programs inside of the container that attempt to detect hardlinks by collecting (dev, inode) values from files that have st_nlink > 1.