[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #24342] -inum predicate shoud use dirent.d_ino instead of stat
Re: [bug #24342] -inum predicate shoud use dirent.d_ino instead of stat.st_ino
Sun, 8 Mar 2009 15:32:36 +0000
[ 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
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
> Every S_IFxxx I can find, *except* Masscomp's S_IFCTG (contiguous
> file), which my Google-fu cannot find a numeric value for:
> 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 */
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.
Re: [bug #24342] -inum predicate shoud use dirent.d_ino instead of stat.st_ino, George Spelvin, 2009/03/08