According to this kernel commit, Linux did not treat d_ino == 0 as a special case, it is a valid inode number. The commit does not change existing inode numbers, so we should still fix the glibc bug which causes it to skip directory entries with d_ino == 0. commit 2adc376c551943a07170cbe70f43e6d6065f8906 Author: Carlos Maiolino <cmaiolino@redhat.com> Date: Thu Jun 25 12:25:58 2015 -0300 vfs: avoid creation of inode number 0 in get_next_ino currently, get_next_ino() is able to create inodes with inode number = 0. This have a bad impact in the filesystems relying in this function to generate inode numbers. While there is no problem at all in having inodes with number 0, userspace tools which handle file management tasks can have problems handling these files, like for example, the impossiblity of users to delete these files, since glibc will ignore them. So, I believe the best way is kernel to avoid creating them. This problem has been raised previously, but the old thread didn't have any other update for a year+, and I've seen too many users hitting the same issue regarding the impossibility to delete files while using filesystems relying on this function. So, I'm starting the thread again, with the same patch that I believe is enough to address this problem. Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
I reported this only a few years ago: https://sourceware.org/bugzilla/show_bug.cgi?id=12165 FWIW, Google carries a local patch to fix this.
This was already reported in 2010. *** This bug has been marked as a duplicate of bug 12165 ***