Subject: Re: bug#61884: add an option to du that allows to control which file types are counted

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 05 Mar 2023 00:33:00 +0100

On Sat, 2023-03-04 at 14:58 -0800, Paul Eggert wrote:
> What's the motivation here? Does this have something to do with 
> reproducible builds?

No, nothing with reproducibility - at least not from my side. It's
really just to get a number for the "actual" data. And yes it's clear
that one can argue what that actually is ;-) ... but at least I think
it should give the same totals for the same files (of any type) on any
filesystem.

> One possibility is for --apparent-size to always count 0 for 
> directories, since 'read' never returns a positive number on 
> directories. That is, we reinterpret --apparent-size to mean "bytes
> that 
> could be read" rather than "what st_size says".

Sounds like having a good potential for breaking existing stuff.

And in a way solve the fundamental problem only partially:

As said above, it's not even clear what "actual" or "pristine" data
should actually be.

I would say that it's at least independent of any underlying structures
(like meta data of a filesystem or e.g. header data in a tar archive).

But would symlinks (i.e. their length) count for it?
What about hardlinked files, would they count once or n times?

du already allows to select what it should do for hard links (-l) so I
figured it would fit conceptually if it would allow the same for file
types.
E.g. with a --type option that takes a string of (1-n) letter like
find:
              b      block (buffered) special
              c      character (unbuffered) special
              d      directory
              p      named pipe (FIFO)
              f      regular file
              l      symbolic link
              s      socket
              D      door (Solaris)

If --type is given only the files with letters are counted (but it has
no effect on whether such files are followed or recursed into (in the
case of d or l).

But anyway... as said previously... I already have my script that does
more or less what I want.
So if you think the whole idea is overkill for du, then don't hesitate
to close as wontfix.

Cheers,
Chris.