From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 13 Jan 2012 18:02:19 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120113170219.GA877@polynum.com> References: <20120113113026.GA419@polynum.com> <20120113133836.GA484@polynum.com> <20120113140834.GA849@polynum.com> <20120113160142.GA98@polynum.com> <20120113171734.77a40595@wks-ddc.exosec.local> <20120113164101.GB647@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120113164101.GB647@polynum.com> User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] fossil pb: FOUND! Topicbox-Message-UUID: 5a905d8c-ead7-11e9-9d60-3106f5b1d025 On Fri, Jan 13, 2012 at 05:41:01PM +0100, tlaronde@polynum.com wrote: > > > > See /lib/namespace. > > Yes, but reading "Getting Dot-Dot right" by Rob Pike, I thought that the > solution was to have, underneath, one uniq pathname for a file. Date(1) > can format UTC; whatever the user presentation, underneath there is only > the UTC. Namespace is a way to manage the nicknames, or the presentation > of data; to manage different views of the "real" thing, but underneath > there is an uniq pathname; a pathname finally resolved to something > (no infinite recursion). Answering to myself: du(1) -s make the sum of each entry it has printed. If the entries are repeated (because of multiple binds), it appears in the sum. So du(1) does what it says; the sum. I never thought that perhaps, under Unices, du(1) with hard links will produce the same misleading result... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C