Re: Bug#367691: coreutils: behaviour of du -x[LDP] differs from that of du -[LDP]x

[Jim Meyering]

Justin Pryzby <address@hidden> wrote:
...
> I don't think this is right.

If you can come up with an example where it fails,
I'd appreciate it -- and would add a test case.

> Quoting the manpage:
> |    There are a number of options, at least one of which (either FTS_LOGICAL
> |    or FTS_PHYSICAL) must be specified.  The options are selected by or'ing
> |    the following values:
>
> so this will supposedly cause du to fail if -D is given.  I just wrote
> a small test for this, and it appears to be false that (exactly?) one
> of FTS_{LOGICAL,PHYSICAL} must be set.  The fts_{open,children,close}
> all succeed.  I'm going to bug manpages about this (and some other
> things).

Bear in mind that the man page documents glibc's fts.
The coreutils one has been able to evolve, and as such
has some incompatible ABI changes, and recently, some
upward-compatible API changes.

> In any case, it is my understanding that FTS_COMFOLLOW is really an
> independent option, and so should be handled as an bit_flag.

Good point.
Here's the additional change I'll probably make, along
with the name change s/symlink_deref_bit/symlink_deref_bits/.

Index: src/du.c
===================================================================
RCS file: /fetish/cu/src/du.c,v
retrieving revision 1.225
diff -u -p -r1.225 du.c
--- src/du.c    19 May 2006 12:36:18 -0000      1.225
+++ src/du.c    19 May 2006 14:47:48 -0000
@@ -807,7 +807,7 @@ main (int argc, char **argv)
          break;
 
        case 'D': /* This will eventually be 'H' (-H), too.  */
-         symlink_deref_bit = FTS_COMFOLLOW;
+         symlink_deref_bit = FTS_COMFOLLOW | FTS_PHYSICAL;
          break;
 
        case 'L': /* --dereference */

I'll also change fts.c to make fts_open fail if you call
it with neither FTS_PHYSICAL nor FTS_LOGICAL.