From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 16 Jan 2012 12:55:45 +0100
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20120116115545.GB618@polynum.com>
References: <201201160739.q0G7dDXS024165@freefriends.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201201160739.q0G7dDXS024165@freefriends.org>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [9fans] du vs. ls: duplication or not?
Topicbox-Message-UUID: 5cfa4196-ead7-11e9-9d60-3106f5b1d025

On Sun, Jan 15, 2012 at 11:39:13PM -0800, arnold@skeeve.com wrote:
> 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.

That's indeed a reason, showing that ls(1) is more on the abstract level
(whatever the implementation, ls(1) shows ownership and permissions
---that can have no real relationship in the actual store) while du(1)
tries to show effective story and needs to know more about effective
storage.

And it can work only with some filesystems. (Think ftpfs etc. and think
sharing of blocks)

Unix du(1) seems more accurate simply because it is used in a more
limited context (of filesystems).

So the question remains for me: whether use the fscons, or ls(1) if no
fscons(1). But does a du(1) have to exist?
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C