From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 15 Jan 2012 23:39:13 -0800
From: arnold@skeeve.com
Message-Id: <201201160739.q0G7dDXS024165@freefriends.org>
To: 9fans@9fans.net
Subject: Re: [9fans] du vs. ls: duplication or not?
Topicbox-Message-UUID: 5cd50e62-ead7-11e9-9d60-3106f5b1d025

Hi.

> What I meant was the size of the file is already given via ls(1). So
> a recursive output that make sense and fit a manipulation via join(1)
> (to combine a srv/qid) and sort and uniq etc. could do the trick.

Not quite. On Unix (don't remember 'bout Plan 9 but I assume it's the
same) files can have holes.  All you have to do is lseek pass the end of
the file and then write something.  Bingo - size (or better, length of
the byte stream) no longer has a direct relationship to the number of
disk blocks occupied.

On Unix systems, du looks in the stat structure at the count of
blocks occupied (st_blocks IIRC) and does the computation from that.
Similaly, many Unix du implementations will track hard links based
on device+inode to only count a file's blocks once.

> Since ls(1) gives the size of the file; since du(1) can not really or at
> least not always in an arbitrary context tells the "real" occupation of
> disk size, is not ls(1) enough?

For the two above reasons, I think not.  Again, at least on Unix. :-)

(I suppose ls could print device+inode, and sort+join on that to remove
duplicates, but the holes problems is still there.  Hmmm. I bet ls can
print the number of blocks instead of or in addition to the size. So
maybe I'm wrong after all. :-)

Arnold