Things are not quite this simple. There are two different concepts of size here.
The 1558 does mean that a program can read 1558 bytes from this files. An attempt to read byte 1559 will fail with an EOF being returned. This is one concept of size.
But I think that Alan is actually interested in the second concept which is how much disk space is consumed by the file. The answer is that 8 * 512 = 4096 bytes of disk space is being using by this file. And that 8 came from the first column of the "ls" listing.
So if a program adds a byte to the file, making that 1558 to be a 1559, no additional disk space is needed.
This difference becomes very important because unix supports sparce files. If Alan wrote a program that seeks to byte 1,999,999,999 and writes a single byte, he will see something like this:
16 -rwx------ 1 root sys 2000000000 Dec 30 14:06 sparsefile
(Hmmmm... I would have predicted 8. Apparently a full block was allocated instead of a fragment. This was on HP-UX 11.00 on a vxfs filesystem.)
Database programs like Oracle will do this so it happens more often than you may think.
Here is my program in case you'd like to try it...
Code:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
main()
{
int fd;
char byte=0;
fd=open("sparsefile", O_CREAT|O_RDRW, 0700);
lseek(fd, 1999999999, SEEK_SET);
write(fd, &byte, 1);
close(fd);
exit(0);
}
