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.
