From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 14 Jan 2012 09:01:06 +0100
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20120114080106.GA807@polynum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Content-Transfer-Encoding: quoted-printable
Subject: [9fans] du vs. ls: duplication or not?
Topicbox-Message-UUID: 5b449068-ead7-11e9-9d60-3106f5b1d025

This is a slightly different point of view from the thread my blunders
have started.

du(1) stands for Disk Usage. But does this, with the "historical" use,
has any real sense now, with a namespace that can be, not only built by
presenting a same file via different paths, but a combination of local
storage (including memory one...) and remote storage?

Furthermore, even for an Unix du(1), if the underlying filesystem shares
common blocks, the count will be wrong. So Unix du(1) seems more
accurate only when it is used on "old" technology.

So if du(1) should stand for Disk Usage, it should tell what disk place
would be needed to _store_ "locally" the files. And this depends
on a lot of things: deduplication of blocks? If one uses a FAT, it
will need the total amount displayed etc.

So, in fact, since there is no real and immediate answer, and keeping in
mind the principle: don't duplicate fonctionnality, wouldn't it be
better to have a 'ls -R' (r=E9cursive listing) and no du(1) at all on
Plan9?

This is not a proposal or whatever. But, say, a semantical and
engineering question. And BTW, this is not a critic of what has been and
is done on Plan9. (I finally consider that du(1) does what it promises
in the man page; the "lack" is just a one line caveat that du(1) can not
answer a fuzzy question.)
--=20
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C