Subject: Re: du does not find all directories
From: [email-masked] (Jim Balter)

8 Feb 1997 18:51:22 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Original-To: Ken Evans <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Original-Sender: [email-masked]

Ken Evans wrote:

>      My experience is that du reports in 2K blocks (based on
> comparison to ls and DOS dir), independently of -k.  The number that
> appears seems to be half the number of kB.

Yes, I've already explained this a few times, based upon what the code
does.

> (Whether this is half as
> many as it "should" report depends on what you think it "should"
> report.  The versions of du I use on Unix default to 512K blocks.)

GNU du is documented as defaulting to 1K blocks unless the
POSIXLY_CORRECT environment variable is set, as I've already explained.
Read the man pages.

>      MORE IMPORTANTLY, du is not reporting all my directories.  I get:
> 
> du:        333347 -> 682,694,656 Bytes
> 
> scandisk:             36,503,552 in 1,111 folders
>                       17,760,256 in 225 hidden files
>                    1,836,875,776 in 25,348 user files
>                      255,328,256 available
>                    2,146,467,840 total
>                           32,768 in each allocation unit
>                           65,505 allocation units
> 
> tape backup:       1,210,603,864 (last time, approx. same files as now)
> 
>    The discrepancy between the tape backup number and scandisk is
> apparently the wasted space owing to allocation by cluster as
> mentioned above.  Nevertheless, du is reporting roughly half as much
> as the tape backup.  Even if you want to argue that the tape backup
> software is wrong, the du output clearly does not include all of the
> directories on the drive.  It is missing whole directories.

du doesn't report a file or directory if it matches a previously
seen inode number, but cygwin's inode number implementation is broken,
as I've already explained.

I've also explained how you can fix du to not miss directories
and to not divide the number of 1K blocks by 2.  I've also explained
that that still won't be sufficient because cygwin's st_blocks
doesn't account for clustering.  Are my postings not reaching your
mailbox?

--
<J Q B>
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".