The longer entries are seems to be on different filesystems:
dev:801 ino:2 name:/
dev:6 ino:2 name:/dev
dev:18 ino:2 name:/run
dev:3c ino:2
name:/var/lib/docker/containers/e1c046bb5a81c469a8df15d2120ef0279c00537034d12b16ecf662b8ee373965/mounts/shm
dev:95 ino:2
name:/var/lib/docker/containers/9deea768c8f6c63a729cfb05fdbe0c0bd94ba0a3acf5d855a90cea59f6d275cb/mounts/shm
dev:3b ino:2
name:/var/lib/docker/containers/2c84000c9de461357cb839291b8f6b85224cbf83e4a834bb2be0c07971914047/mounts/shm
dev:3e ino:2
name:/var/lib/docker/containers/f1cad304f57c9d037f5d9cdb56dc992d3838ef85456819dedf4e09dfe9f34828/mounts/shm
dev:ca ino:2
name:/var/lib/docker/containers/203d7a788ea761b0c888fd23748049136ac7c506aa67ffb4141bc41c151e0c3a/mounts/shm
dev:c9 ino:2
name:/var/lib/docker/containers/65ba7611be7738ad051b6ba09cd51304dc574bab54def0b140999abdc3a299c6/mounts/shm
dev:94 ino:2
name:/var/lib/docker/containers/255a29fb2b41cd6c541d11b8cdc22e69c8aac5d0cd80b83f04295539f7d9700b/mounts/shm
dev:3d ino:2
name:/var/lib/docker/containers/ed8595232045982ed792d50cbc60ccac3c156b23e9c205c85c3a3e3c830f431d/mounts/shm
dev:c2 ino:2
name:/var/lib/kubelet/pods/a994411d-8f24-4101-9e07-b15e66470dfc/volumes/kubernetes.io~secret/coredns-token-65pjr
dev:8d ino:2
name:/var/lib/kubelet/pods/e1c23a8f-c462-4562-b556-7791be24213e/volumes/kubernetes.io~secret/kube-proxy-token-clxqv
dev:8c ino:2
name:/var/lib/kubelet/pods/e8c0dbfd-3daf-4d5a-8672-8d8311ddf393/volumes/kubernetes.io~secret/flannel-token-x6nrk
dev:c1 ino:2
name:/var/lib/kubelet/pods/91acd716-7fb7-4477-80ef-9aeb5774df17/volumes/kubernetes.io~secret/coredns-token-65pjr
Which -xdev should care about but doesn’t (?) or I should use another option.
I see. Tricky way to find hard links to a dir being a root — `stat -c 'dev:%D
ino:%i name:%n' /*/.. /.` — works to me. Thank you. Seems find as of now can’t
do it?
>Sunday, August 16, 2020 3:44 PM +03:00 from Bernhard Voelker
><m...@bernhard-voelker.de>:
>
>On 2020-08-15 18:56, Andrei Enshin via Bug reports for the GNU find utilities
>wrote:
>> The full out of find is:
>> $ sudo find / -xdev -inum 2 2>/dev/null
>> /
>> /dev
>> /run
>> /var/lib/docker/containers/e1c046bb5a81c469a8df15d2120ef0279c00537034d12b16ecf662b8ee373965/mounts/shm
>> /var/lib/docker/containers/9deea768c8f6c63a729cfb05fdbe0c0bd94ba0a3acf5d855a90cea59f6d275cb/mounts/shm
>> /var/lib/docker/containers/2c84000c9de461357cb839291b8f6b85224cbf83e4a834bb2be0c07971914047/mounts/shm
>> /var/lib/docker/containers/f1cad304f57c9d037f5d9cdb56dc992d3838ef85456819dedf4e09dfe9f34828/mounts/shm
>> /var/lib/docker/containers/203d7a788ea761b0c888fd23748049136ac7c506aa67ffb4141bc41c151e0c3a/mounts/shm
>> /var/lib/docker/containers/65ba7611be7738ad051b6ba09cd51304dc574bab54def0b140999abdc3a299c6/mounts/shm
>> /var/lib/docker/containers/255a29fb2b41cd6c541d11b8cdc22e69c8aac5d0cd80b83f04295539f7d9700b/mounts/shm
>> /var/lib/docker/containers/ed8595232045982ed792d50cbc60ccac3c156b23e9c205c85c3a3e3c830f431d/mounts/shm
>> /var/lib/kubelet/pods/a994411d-8f24-4101-9e07-b15e66470dfc/volumes/kubernetes.io~secret/coredns-token-65pjr
>> /var/lib/kubelet/pods/e1c23a8f-c462-4562-b556-7791be24213e/volumes/kubernetes.io~secret/kube-proxy-token-clxqv
>> /var/lib/kubelet/pods/e8c0dbfd-3daf-4d5a-8672-8d8311ddf393/volumes/kubernetes.io~secret/flannel-token-x6nrk
>> /var/lib/kubelet/pods/91acd716-7fb7-4477-80ef-9aeb5774df17/volumes/kubernetes.io~secret/coredns-token-65pjr
>Those longer entries look strange to me. Are they really on the same file
>system
>(which -xdev should care about)?
>
> sudo find / -xdev -inum 2 -exec stat -c "dev:%D ino:%i name:%n" '{}' +
>
>Here, I'm getting:
>
> dev:802 ino:2 name:/
> dev:803 ino:2 name:/home
> dev:700 ino:2 name:/FULL_PARTITION_TMPDIR
> dev:805 ino:2 name:/media/big_data
>
>As one can see, they all have the inode number 2, but on a different
>file system's device number. These are mount points, and incidentally they
>have the same ino number 2 in their file system respectively.
>This illustrates why -mount will soon have a different meaning than -xdev:
>see https://savannah.gnu.org/bugs/?54745
>and http://austingroupbugs.net/view.php?id=1133
>
>Now to the total number of hardlinks to '/'. Here, I have 24, and the inode
>number is also 2:
>
> $ ls -lidog /
> 2 drwxr-xr-x 24 4096 Aug 3 15:24 /
>
>Now the '/' directory itself (='/.') and all '..' entries in all direct
>sub-directories
>(matched by the pattern '/*/..') are linking to that inode:
>
> stat -c 'dev:%D ino:%i name:%n' /*/.. /. | wc -l
> 24
>
>(Please note that the pattern matching "/*/.." will only result to
>all subdirectories' dotdot entries as 'root'; at least here a regular
>user wouldn't see e.g. '/root/..'. Hence, simply prefixing 'stat' with
>'sudo' wouldn't help, because the pattern matching by the shell is done
>before invoking sudo.)
>
>Have a nice day,
>Berny
---
Best Regards,
Andrei Enshin
