Re: find inodes of a dir

[Bernhard Voelker]

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