-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Adam Borowski on 3/31/2009 1:40 AM: > http://savannah.gnu.org/bugs/?19593 > > Instead of tweaking the docs -- or perhaps in addition to -- let's think how > to fix the behaviour. What about doing a dup() on the directory, and > comparing the paths once the next match is found? That would have a side > effect of delaying execution if there's no match for a long time, but I > think that's still much better than doing just one file.
Doing a dup() is counterproductive. It puts increased pressure on the number of open file descriptors, particularly if your hierarchy is deep, but we don't want to trigger EMFILE failures. Additionally, it triggers bugs in some network filesystems, which report a cached 32-bit inode value; this value is consistent when used with locality of reference, but when stored over a long period of time with a large number of file traversals in between, the cache recycles, and the same file/directory can appear with a different inode. You can search the gnulib mail archives for more details about how fts had to be recoded to avoid triggering this bug, and the impact that it had on coreutils. The real fix has to be an interface change to gnulib's fts to make it obvious when a directory is changing, in order to make it easier for find to group multiple files found from a single directory. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknSNQkACgkQ84KuGfSFAYAqJgCeL06AbvO5kXnArEFbfmQWbEJD MpQAnjfRmC1GNENAHBWFcN3zijJfuxiT =nW6d -----END PGP SIGNATURE-----
