>[This really doesn't belong on port-i386, as just about nothing here is
>i386-specific, as far as I can see.  tech-userlevel maybe?]

Sorry, I chose port-i386 because that's the port I was doing this on.

>  > I suppose it's possible for the amount of disk space allocated to a
>>  sparse file to be the same as its size, and ls -lsh would give the
>>  same numbers for its first and sixth fields?
>
>(a) they're in different units, so the numbers printed won't be the
>same in the case you're thinking of (well, this depends on how -s
>interacts with -h in your ls[%]); and (b) they represent different
>things, so the numbers wouldn't be the same even if they were in the
>same units.

OK, thanks.

>[%] Under 3.1, -h seems to suppress -s for me, though the manpage seems
>to imply that -h makes -s print values in bytes.

It does that on my 3.1 machine too but on this machine:

# uname -rs
NetBSD 3.99.20    <-- from May 2006
# ls -l
total 2
-rw-r--r--  1 root  wheel  94 Jul 31 16:56 file1
# ls -ls
total 2
2 -rw-r--r--  1 root  wheel  94 Jul 31 16:56 file1
# ls -lsh
total 94B
2.0K -rw-r--r--  1 root  wheel   94B Jul 31 16:56 file1
#

>  > In this example, how does 'total 4' correspond to the file size of
>>  seven bytes?
>
>>  $ ls -l
>>  total 4
>>  -rw-r--r--  1 defang  wheel  7 Jul 31 13:49 file1
>>  $ set | grep BLOCK
>>  $
>
>My guess is, your filesystem is a 2k/16k FFS filesystem; a seven-byte
>file actually occupies one whole frag, which is 4 disk sectors.

OK; yes that's right:

# disklabel wd0 | tail -8

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
  a:   4195296        63     4.2BSD   2048 16384 21872  # (Cyl. 
0*-   4162*)
  b:   2097648   4195359       swap                     # (Cyl. 
4162*-   6243*)
  c: 156301425        63     unused      0     0        # (Cyl.      0*- 155060)
  d: 156301488         0     unused      0     0        # (Cyl.      0 - 155060)
  e: 150008481   6293007     4.2BSD   2048 16384 28696  # (Cyl.   6243*- 155060)
#


Ray