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