bin/74567: [patch] [2TB] du doesn't handle sizes >1TB

Brooks Davis brooks at one-eyed-alien.net
Wed Dec 1 08:10:31 PST 2004


The following reply was made to PR bin/74567; it has been noted by GNATS.

From: Brooks Davis <brooks at one-eyed-alien.net>
To: Sergey Salnikov <serg at citforum.ru>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: bin/74567: [patch] [2TB] du doesn't handle sizes >1TB
Date: Wed, 1 Dec 2004 08:07:10 -0800

 On Wed, Dec 01, 2004 at 02:09:33AM +0300, Sergey Salnikov wrote:
 > 	Here goes the patch. Modified du allocates an int64_t for
 > 	every subdirectory and stores the size there and not in
 > 	fts_number.
 
 It seems like off_t would be more appropriate.  Using hard coded types
 like long is what got us in to this mess in the first place. :) Have you
 done any testing to see how expensive this extra malloc is?  It might be
 cheaper to use fts_number until it overflows and then start doing
 allocations.  That would certaintly use more code though.
 
 > 	Maybe fts_number just has to be 64-bit? It will make
 > 	things faster (no need for extra malloc), but
 > 	involves hacking libc.
 
 fts_number can't change size without a library version bump, but I think
 you might be able to add a new entry (assuming there isn't any broken
 code that uses sizeof(FTSENT).
 
 -- Brooks


More information about the freebsd-bugs mailing list