Date: Mon, 27 Jan 2003 08:00:27 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: struct stat and st_blocks
In-Reply-To: <3E346AB9.D6D2C267@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1030127075631.11790A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 26 Jan 2003, Richard Dawe wrote:

> According to SUSv2 'struct stat' should contain an st_blocks member, which is
> the number of blocks allocated for the object.
> 
> Unless people think it's a good idea to add st_blocks, I'm not going to write
> a patch, because it will break backwards binary compatibility.

It's a question of practical needs, as always (given our scarce 
resources).  It's not hard to write the st_blocks support, although it's 
not exactly trivial, either: the issue of ``what is a block and how to 
find that on different types of media'' raises its ugly head again.  The 
important question is, how many programs out there use it without a 
proper configure-time test and some reasonable fallback in case it is 
not supported.

> coreutils 4.5.4 uses st_blocks in the 'stat' program.

What does `stat' do if st_blocks is not supported?  Is the degradation in 
functionality significant?