Re: find inodes of a dir

Bernhard Voelker <[email protected]>
Newsgroups gmane.comp.gnu.findutils.bugs
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.