The Austin Group ruled in:
that the use of d_type shortcuts during nftw() has resulted in an unintentional regression in glibc:
"Until glibc 2.3.6, in the io/ftw.c process_entry() code, we find:
if (((data->flags & FTW_PHYS)
? LXSTAT (_STAT_VER, name, &st)
: XSTAT (_STAT_VER, name, &st)) < 0)
if (errno != EACCES && errno != ENOENT)
result = -1;
else if (!(data->flags & FTW_PHYS)
&& LXSTAT (_STAT_VER, name, &st) == 0
&& S_ISLNK (st.st_mode))
flag = FTW_SLN;
flag = FTW_NS;
So, if FTW_PHYS was not set, use stat() on the path. If that fails (because of a dangling symlink, for example), then try lstat() on the path and check if the result is symlink; if so, emit FTW_SLN.
In glibc 2.4 (~2006) things changed to the situation we currently have. The change *appears* to be an unintended regression, since the associated changelog message make no mention of modifying the behavior of FTW_SLN.
So, I do think this is a glibc bug, not a fault in the standard, per se (though the standard could be a little clearer).
As this regression is not standards compliant, glibc needs to perform an lstat (perhaps only when POSIXLY_CORRECT is set?) even when using d_type to shortcut the knowledge that a dangling symlink has been found.
The master branch has been updated by DJ Delorie <firstname.lastname@example.org>:
Author: DJ Delorie <email@example.com>
Date: Wed Jun 19 17:07:41 2019 -0400
nftw: fill in stat buf for dangling links [BZ #23501]
As per Austin Group interpretation, "the object" wrt a
dangling symlink is the symlink itself, despite FTW_PHYS.
Reviewed-by: Tulio Magno Quites Machado Filho <firstname.lastname@example.org>
Please set the target milestone appropriately for the first mainline
release in which this is fixed.