On Tue, Feb 08, 2005 at 12:49:39PM -0800, Paul Eggert wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > > If so, please document this properly with %s, 'optimal transfer' is a > > bit a vague term. > > Thanks for mentioning this. There are several other doc. glitches > nearby. I installed this patch; I'm not sure whether it answers your > question (if not, please suggest wording improvements).
Thank you for looking into it, but actually, I think it doesn't answer all the points raised in the thread: - First, for people looking for the 'real blocksize', in the sense of 'the blocksize with which to multiply free/total blocks with to get free/total space of a filesystem in bytes', it is still not clear that there is currently no way to get this from stat(1). Until point two is addressed somehow, it'd be advantegeous for users to see explicitly stated in the documentation that no such parameter exists. - Second, and this is actualy a somewhat seperate issue (because feature request, not documentation clarification request), the 'statvfs(2) glibc call actually DOES return this said block size (f_frsize) as opposed to only f_bsize (prefferd unit size for efficient I/O). See http://bugs.debian.org/294206#msg17 for more information, bottom line is that statvfs returns a superset of values compared to statfs, and one of the extra values is f_frsize required for getting the free disk space in bytes. Thanks a lot, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
