Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.citi.umich.edu!rees
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: re: SR10.3 file system changes ?
Message-ID: <51ff22e3.1bc5b@pisa.citi.umich.edu>
Date: 5 Jun 91 21:44:33 GMT
References: <9106051318.AA01565@pan.ssec.honeywell.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 12

In article <9106051318.AA01565@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:

  3) The Unix 'ls' command gives the total space of a sparse object, not just
     the allocated part.

I don't think that's true.  The length of the file (as reported by 'ls -l')
is just the seek key of eof (to use Aegis-speak).  But the size (as reported
by 'ls -s') is the true (allocated) size (modulo 1k/4k bugs in stat()).

The 'ls' man page is wrong about this, by the way, or at least misleading.
It uses the term "size" to mean both length and size.  This concept is
confusing enough without the documentation contributing to the chaos.