Re: [9fans] du vs. ls: duplication or not?

[arnold@skeeve.com]

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