bug-gnulib
[Top][All Lists]
Advanced

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

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs,


From: Jim Meyering
Subject: Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...
Date: Fri, 13 Oct 2006 14:17:38 +0200

Miklos Szeredi <address@hidden> wrote:
> I've tried out the CVS version of findutils+gnulib, and it does indeed
> seem to fix the problem with inode-less filesystems, in addition to
> using noticably less system time.
>
> I've also found that the -xdev option of find no longer works: it
> outputs just a single line for the base directory.

Thanks for reporting that.
That's a bug I introduced yesterday.
With FTS_XDEV, p->fts_statp->st_dev is used uninitialized.
Here's the patch I'll probably commit.  Need more tests, first...

        Fix a bug in yesterday's change.
        * lib/fts.c (fts_open): When using FTS_XDEV|FTS_NOSTAT,
        p->fts_statp->st_dev would be used uninitialized.
        Ensures that we always call fts_stat on the very first entry.
        Miklos Szeredi reported that find -xdev stopped working.

Index: lib/fts.c
===================================================================
RCS file: /sources/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.21
diff -u -r1.21 fts.c
--- lib/fts.c   12 Oct 2006 10:36:51 -0000      1.21
+++ lib/fts.c   13 Oct 2006 12:15:55 -0000
@@ -396,7 +396,7 @@
                p->fts_level = FTS_ROOTLEVEL;
                p->fts_parent = parent;
                p->fts_accpath = p->fts_name;
-               if (defer_stat) {
+               if (root != NULL && defer_stat) {
                        p->fts_info = FTS_NSOK;
                        fts_set_stat_required(p, true);
                } else {

> Looking at the strace, there's still a possibility for an optimization
> on systems which have both O_DIRECTORY and O_NOFOLLOW.
>
> This:
>
>   lstat64("foo", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
>   open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
>   fstat64(5, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
>
> Could be replaced with this:
>
>   open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW) = 5
>   fstat64(5, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
>
> since the lstat becomes unnecessary, once the open is sure to fail on
> anything non-directory.

Yes, it can be.  However, I think you'll understand if I don't
look into that just yet.




reply via email to

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