Re: [bug #24342] -inum predicate shoud use dirent.d_ino instead of stat.st_ino

[James Youngman]

[ adding nug-gnulib to CC since we're discussinf its fts implementation ]

On Sun, Mar 8, 2009 at 2:50 PM, George Spelvin <address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>> The updated patches are what I actually pushed (into 4.5.x).
>
> Ah, thank you.  The posted patches wouldn't apply to savannah git HEAD
> due to a conflict in the ChangeLog.  (Easy enough to work around, but
> worrisome.)

They're *in* HEAD.


>
> The (tested) simplified version is, of course,
> +  boolean todo = pred_ptr->need_stat ||
> +              (pred_ptr->need_type && !state.have_type) ||
> +              (pred_ptr->need_inum &&
> +               (!p->st_ino || !state.have_type || S_ISDIR(p->st_mode)));
>
> I poked at the leaf optimization, but it appears I'd have to change the
> prototypes for the entire predicate system, which is extremely annoying.

Yes.   I also believe it would gain little, since in the case of
ftsfind at least, leaf is normally 0.


> One option is to understand the "state" structure and how its contents
> relate to the predicate arguments.  I'm currently very confused by that.

The state structure contains a bunch of what would otherwise be global
variables.   The struct preidcate instances represent tests or actions
specified on the command line.  With a few exceptions (for example
struct predicate_performance_info) the information in struct predicate
is unchanged after we begin traversing the filesystem.


> The other is to pack the dirent info into the existing struct stat.

fts copies d_ino and d_type into the stat structure which is passed as
the first argument to the predicate functions.   d_name ends up in the
pathname argument of the predicate functions.

> I'm thinking about that.  One possibility is to have some file type
> bits that mean "you'll need to call stat(2) for details, but it's NOT
> a directory".  For example, st.st_mode == 1.

Yes, fts() will normally know this, but I don't think we can rely on
ftsent->fts_parent->fts_n_dirs_remaining.   However, we may be able to
make use of FTS_NSOK.

In the case of "find -P -samefile" we can know in advance whether the
inode corresponds to a directory or not, but this doesn't help the
-inum test.


>
> Every S_IFxxx I can find, *except* Masscomp's S_IFCTG (contiguous
> file), which my Google-fu cannot find a numeric value for:
> 0000
> 0001 FIFO
> 0010 CHR
> 0011 MPC        /* Multiplexed char device: V7 & Coherent */
> 0100 DIR
> 0101 NAM        /* Xenix special named file */
> 0110 BLK
> 0111 MPB        /* Multiplexed block device: V7 & Coherent */
> 1000 REG
> 1001 NWK        /* HP-UX network special */
>     CMP        /* VxFS compressed */
> 1010 LNK
> 1011 SHAD       /* Solaris shadow inode for ACL, not seen by userspace */
> 1100 SOCK
> 1101 DOOR       /* Solaris door */
> 1110 WHT        /* BSD whiteout, not seen by userspace */
> 1111
>

FWIW, some broken NFS servers (or perhaps NFS servers serving
corrupted filesystems) return invalid st_mode values; Savannah bug
#16378 at https://savannah.gnu.org/bugs/?16378 gives an example.

Thanks,
James.