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
