Date:	Wed, 12 Jul 2000 18:15:35 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: Filetree disk size
In-Reply-To:	<Pine.LNX.4.10.10007121229440.32191-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1000712181146.4113E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 12 Jul 2000, Hans-Bernhard Broeker wrote:

> Speaking about 'du':
> 
> > Unfortunately, it also doesn't take the exact cluster size into account, 
> > so the size it prints is always less than the actual size.
> > 
> > Perhaps a future port of Fileutils could take care of this.
> 
> I'm not too sure. That had better be introduced not in the DJGPP port, but
> as a new feature to the FSF version, and then implemented for all ports
> using FAT filesystems, simultaneously.

It's a simple change, and is a useful feature to have.  `du' expects the 
library to return the block size, and if it does not, falls back to some 
simple-minded default.  All it takes to fix that is to compute the block 
size dynamically.

> 'du' is traditionally defined to disregard any filesystem chunkyness. So
> it works in terms of bytes, and only displays the result as sector counts
> (512 bytes per sector, says POSIX).

I'm not sure this is all there is to it.  IIRC, `du' expects `stat' or 
some other system call to return the actual block size, and uses that if 
it's available.  We didn't have the appropriate field in struct stat at 
the time, so I tricked `du' to use its fallback.

- Raw text -