12

Please, only people that have used the "uutils coreutils" version of the du command should comment.

Compare the following outputs of the commands ran on an Ubuntu 25.10 system:

# du -smc /var
8670    /var
8670    total

# du -smc /var/log 
1548    /var/log
1548    total

# du -smc /var/log /var
1548    /var/log
8670    /var
10217   total

# du --version
du (uutils coreutils) 0.2.2

vs:

# /snap/core22/2134/usr/bin/du -smc /var
8670    /var
8670    total

# /snap/core22/2134/usr/bin/du -smc /var/log
1548    /var/log
1548    total

# /snap/core22/2134/usr/bin/du -smc /var/log /var
1548    /var/log
7122    /var
8670    total

# /snap/core22/2134/usr/bin/du --version
du (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.

Is this a bug in the "new" Rust-based utilities?

# type du
du is hashed (/usr/bin/du)

# ls -l /usr/bin/du
lrwxrwxrwx 1 root root 29 Sep 26 21:16 /usr/bin/du -> ../lib/cargo/bin/coreutils/du

If this is not a bug, how can I get the size of /var/log, the size of the rest of /var (excluding /var/log), and the correct summary of the whole size of /var as given by the GNU version of du?

This has nothing to do with the "varying contents" of the /var directory. As another example see this:

$ du -smc /usr
8010    /usr
8010    total

$ du -smc /usr/bin
636 /usr/bin
636 total

$ du -smc /usr/bin /usr
636 /usr/bin
8010    /usr
8646    total

$ du -smc /usr /usr/bin
8010    /usr
636 /usr/bin
8646    total

vs:

$ /snap/core22/2134/usr/bin/du -smc /usr
8010    /usr
8010    total

$ /snap/core22/2134/usr/bin/du -smc /usr/bin
636 /usr/bin
636 total

$ /snap/core22/2134/usr/bin/du -smc /usr/bin /usr
636 /usr/bin
7374    /usr
8010    total

$ /snap/core22/2134/usr/bin/du -smc /usr /usr/bin
8010    /usr
8010    total
Improve this question
3
  • Repeated dus on a directory (/var, /var/log) that has wildly varying contents produces inconsistent results. Compare on low-churn directory trees. /usr, /lib, etc. Commented Nov 7 at 22:10
  • 2
    I wonder if rust du is not doing link counting? Try mkdir test; cd test; touch link; du -s --inodes ; ln link link2; du -s --inodes should get the same result twice Commented Nov 8 at 12:50
  • 7
    It is wrong, but is memory-safe. Commented Nov 9 at 7:13

2 Answers 2

Reset to default
16

From the uutils repo:

uutils coreutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

While that may be too broad a statement, I would consider your example to be a bug as the starting position based on this.

Also, the fact that the subdirectory is counted twice in the total just doesn't seem to be logical, and I would consider a bug (or at least poor result) even if this was a "new tool" (rather than a drop-in replacement).

Improve this answer
4
  • Exactly! Note that I haven't found a bug report like this in github.com/uutils/coreutils/issues Shall I create a new bug report? Commented Nov 8 at 18:49
  • 2
    I think so - but keep in mind (since you can see muru's deleted answer) that the POSIX spec seems to leave this undefined, so the priority in fixing it might not be that high. Commented Nov 8 at 22:39
  • @NotTheDr01ds Although this bug is interesting, if it's a bug shouldn't the question be closed? Commented Nov 9 at 16:08
  • 2
    @WinEunuuchs2Unix I considered that, but the real question was "is it a bug or is there a workaround"? That's a bit different, IMHO. And an answer that it should be considered a bug doesn't necessarily mean the original should be closed. Commented Nov 9 at 20:06
12

While the 2018 edition we have:

It is implementation-defined whether a file that occurs under one file operand is counted for other file operands. The directory entry that is selected in the report is unspecified.

And in the 2024 edition:

A file that occurs multiple times shall be counted and written for only one entry, even if the occurrences are under different file operands. The directory entry that is selected in the report is unspecified.

So it is a very much an ordering problem. On my Arch Linux system, I see this:

% sudo du -smc /var/log /var
1540    /var/log
33954   /var
35494   total

% sudo uu-du -smc /var/log /var
1540    /var/log
35494   /var
37033   total

% sudo busybox du -smc /var/log /var
1540    /var/log
33954   /var
35494   total

Busybox agrees with GNU, but as this is clearly an argument ordering problem, what happens when I switch the order?

% sudo du -smc /var /var/log 
35494   /var
35494   total
% sudo uu-du -smc /var /var/log
35494   /var
1540    /var/log
37033   total
% sudo busybox du  -smc /var /var/log                      
35494   /var
35494   total

And again Busybox agrees with GNU, both of them changing the output but uu-utils remains consistent!

TBH, my takeaway from this is to avoid using overlapping directories in a single du invocation.

Improve this answer
1
  • 4
    for gnu du version ≥ 9.5 (the OP is on 8.32), the output varies depending on POSIXLY_CORRECT. As 8.32 was likely written to the 2018 edition, it doesn't know about the change in the standard. Commented Nov 9 at 17:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.