bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Advantages of using struct dirent.d_type in preference to lstat


From: James Youngman
Subject: Advantages of using struct dirent.d_type in preference to lstat
Date: Wed, 22 Dec 2004 23:46:22 +0000
User-agent: Mutt/1.3.28i

This conversation is no longer much to do with the original bug report
but is certainly interesting.  Hence I have moved the conversation to
email on the address@hidden mailing list, because otherwise
every time the bug report is updated with new remarks, everyone on the
list will get a repeat post of the entire history of the bug.

On Wed, Dec 22, 2004 at 05:09:36PM -0500, Egmont Koblinger wrote:

> On recent systems, the "struct dirent" returned by readdir()
> contains a d_type field which might (but not necessarily
> does) provide information about the file type. E.g. it can
> be DT_UNKNOWN meaning that stat() has to be performed in the
> old-fashioned way to get the file type, but in the mean
> time, it can also be DT_REG, DT_DIR and so on (see
> /usr/include/dirent.h).

Yup, this is on my list of things to do.  It means modifying (or
forking) gnulib's savedir.c.  In my notional set of priorities, this
comes after the implementation of "-exec ... {}+" (which is required
for POSIX compliance) and "-execdir ..." (which is an important
security enhancement).  That's the order in which I plan to do things,
but if someone else gets round to implementing a patch and dontaing it
to the FSF, I'll apply it.

> It would be very nice then if findutils, whenever available
> (I know, both compile-time and run-time detection is needed,

Well, for simplicity when I change savedir.c, if it is being used on a
system where d_type is not provided, DT_UNKNOWN will be recorded for
every file.  The "have_stat" variable in find.c will have to become a
tristate (have nothing, have file type, have full stat info) and
needs_stat will have to undergo a similar transformation.

> - would be even faster than the current way since much more
> stat() calls can be avoided,

Absolutely.  Once d_type is supported, I suspect that find will only
ever stat directories it changes into (in wd_sanity_check) unless
a) one of the predicates specified on the command line requires
   knowledge of something other than the file's type (e.g. -size, 
   -inum, -newer)
or 
b) the -L option is in effect (in which case we will have to stat anything 
   with d_type == DT_LNK in order to supersede DT_LNK with the type of the 
   linked-to file)

> - would be a perfect workaround for the kernel's /proc/PID
> hardlink count problem.

Yes, if we already have d_type and it is DT_DIR, we can ignore
"noleaf".

James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]