Your message dated Thu, 24 Jan 2008 20:08:44 -0500
with message-id <[EMAIL PROTECTED]>
and subject line coreutils: behaviour of du -x[LDP] differs from that of du
-[LDP]x
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: coreutils
Version: 5.94-1
Severity: normal
I was reading du.c, and saw this:
int bit_flags = FTS_PHYSICAL | FTS_TIGHT_CYCLE_CHECK;
[...]
case 'x':
bit_flags |= FTS_XDEV;
break;
[...]
case 'D': /* This will eventually be 'H' (-H), too. */
bit_flags = FTS_COMFOLLOW;
break;
case 'L': /* --dereference */
bit_flags = FTS_LOGICAL;
break;
case 'P': /* --no-dereference */
bit_flags = FTS_PHYSICAL;
break;
This doesn't make sense to me, and violates the common assumption that
behaviour is independent of the ordering of independent command-line
arguments. I'm not claiming that eg. du -LP should be the same as du
-PL (since -P and -L specify opposite behaviour).
I claim only that, since -x is independent of the other flags
(-[HLP]), specifying another flags should have no effect on the state
of -x.
A patch (assuming I understand the intended state of things) would
look something like:
bit_flags|= FTS_COMFOLLOW;
[...]
bit_flags = FTS_LOGICAL;
bit_flags&=~FTS_PHYSICAL;
[...]
bit_flags|=FTS_PHYSICAL;
bit_flags&=~FTS_LOGICAL;
This also avoids clearing FTS_TIGHT_CYCLE_CHECK, which I'm guessing is
not intentional?
--- End Message ---
--- Begin Message ---
Version: 6.10-1
New upstream relase contains fix.
--- End Message ---
