GNU bug report logs -
#10561
stat unclear about size on disk and type of blocks discussed
Previous Next
Full log
Message #43 received at 10561 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 13 years and 185 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.