From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 16 Jan 2012 08:24:42 -0500
To: 9fans@9fans.net
Message-ID: <c1747b7ecf048734a2f7ef59f636ddc6@brasstown.quanstro.net>
In-Reply-To: <201201160739.q0G7dDXS024165@freefriends.org>
References: <201201160739.q0G7dDXS024165@freefriends.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] du vs. ls: duplication or not?
Topicbox-Message-UUID: 5d17d710-ead7-11e9-9d60-3106f5b1d025

On Mon Jan 16 02:40:52 EST 2012, 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.

a plan 9 file server have holes as an implementation detail, but they
wouldn't exist at the protocol level, and therefore d->size is still good enough.

you can't seek to the end of a pipe on plan 9.

- erik