[Top][All Lists]
[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.
- Advantages of using struct dirent.d_type in preference to lstat,
James Youngman <=