bug#10561: stat unclear about size on disk and type of blocks discussed

[Filipus Klutiero]

Hi Eric,

On 2012-02-07 14:44, Eric Blake wrote:
> On 02/07/2012 12:20 PM, Filipus Klutiero wrote:
> > So are you saying that stat cannot display a file's size on disk?
> Not without inventing a new % modifier, or else you doing the math
> yourself.

Thank you very much.

I apologize for much of what I said in this report. I started with the 
assumption that stat could display the size on disk. When I saw that no 
field other than %o contained that, that %o's description read "I/O 
block size" and that %o indeed matched the size on disk for one file, I 
concluded that %o meant size on disk. It turns out that was just a 
coincidence, which happens only when a file fits in a single block.

Please disregard everything I said about %o. From this point, please 
consider this bug report to be only about the descriptions of %b and %B.

>    So maybe it is worth adding a new one, as in:
>
> %S  Allocated size (same as %b * %B)

Absolutely. I requested that in #10755: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10755
> > > I don't see any ambiguity. %b and %B are described in relation
> > > to each other, which is all that's required.
> > That's not all that's required. Each directive should have a useful
> > description, not just a circular definition.
> > > See how each refers to the other in the docs:
> > >
> > >     %b     Number of blocks allocated (see %B)
> > >     %B     The size in bytes of each block reported by %b
> > I see that, but I fail to see how that would make the description of %b
> > unambiguous. A file has a number of file system blocks allocated. I do
> > not see what would prevent a reader from interpreting %b as that number.
> Maybe it would help to do things like:
>
> %b   Number of blocks allocated (see %B), corresponds to st_blocks
> %B   The size in bytes of each block reported by %b, or st_blksize
>
> for those that are familiar with the stat(2) interface.  For that
> matter, tying ALL of the existing % modifiers back to struct stat
> members might be handy.

Probably. I am not familiar with stat(2), and although that would indeed 
provide a way to decide which sense is meant, it would not be a very 
accessible one to me.
I still recommend to specify the type of blocks discussed. Based on 
Pádraig's explanation, I believe a reference to "physical blocks" rather 
than "blocks" would address the problem.