On 2020-08-16 15:01, Andrei Enshin via Bug reports for the GNU find utilities wrote: > > 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
Okay, that explains it: they are all mount points, and the entries in those file systems all have inode number 2. > Which -xdev should care about but doesn’t (?) or I should use another option. Well, as stated, in one of the upcoming versions, the -mount option - which is currently a synonym of -xdev - will avoid returning the mount points. > 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. Hardlinks to directories are only possible via the '..' entries. AFAIR on older or strange systems one could also create such hardlinks, but common current systems reject this: $ ln -v / hardlink-to-root ln: /: hard link not allowed for directory and here is the corresponding failing system call: linkat(AT_FDCWD, "/", AT_FDCWD, "hardlink-to-root", 0) = -1 EPERM (Operation not permitted) > Thank you. Seems find as of now can’t do it? The -inum option only checks for the same inode number, and as -xdev also returns the mount points which could incidentally have the same inum (yet on a different file system), the better choice is -samefile ... as Tavian replied in the other message. However, find will elide the '..' entries. Have a nice day, Berny
