Hi

When I execute the following command: I receive:

why can't I see the whole 28 items?

Are you sure you did not mean the 'ls' command?

Edit: ok. I see what you mean.

I believe you are referring to the "total 28" - that is the total files in the directory and subdirectories...

The number can be deceptive, as a directory always has two links, one to itself, and one to its parent, and you have to deduct those... the real confusion is caused by directories that have directories... each of these has a link to its parent directory, which can inflate the count.

The total is not the number of items but the total number of blocks used by the listed files.
28=4096+4096+16384+4096

The same output can be seen from the output of the ls command (less the parent and self) i.e.
ls -l
or human readable form
ls -lh

Please accept my apology if I say I need more explanation on the equation you have mentioned.

Um...

4096+4096+16384+4096 =28672

if that were a 4k block, 28674/4096 = 7

It would be true if you had a 1K block size... 28672/1024=28

But it doesn't fit my system at all (4k block):

So unless, I'm looking at something wrong, 4+4+8+48+4+4+4+4=80. not 108

Personally, I think the number is useless.

Found a reference... it is the file size / 1024, not block count. What it does for directory size (which is undefined) is not clear. It also seems to drop "." files...

http://archive.download.redhat.com/p...c/install/ls.c

1 members found this post helpful.

What about if you use the -s option...
ls -ls /home

Thanks for the clarification...

In my case, I get the same result as with ls -lh. The block size is reported, but the computation doesn't work. Using the file size/1024 should work... if you can read the directory.

There is some ambiguity, as some filesystems the file length is not normal. The stat(2) man page indicates that the field st_size is the length of regular files and symbolic links. That doesn't work for directories or pipes (either undefined, or invalid). It doesn't work for directories very well because directories on some filesystems may have large holes in the allocation because they use a hash/btree for access speed, thus the block count would indicate a small file, but the file size could indicate a large one. Holes may also occur in regular files in the same way, but they are marked as regular files - and may be copied (a directory can't, when using cp to "copy" a directory, it actually creates a new directory and then copies whatever files are in the original directory to the new directory).

1 members found this post helpful.

I expected the same results. Makes sense.