[ adding nug-gnulib to CC since we're discussinf its fts implementation ] On Sun, Mar 8, 2009 at 2:50 PM, George Spelvin <li...@horizon.com> wrote: > James Youngman <invalid.nore...@gnu.org> 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.
