[SOLVED] how to make "ls" display the real size for directories

louisJ · 04-30-2008, 03:58 PM

hi

I can't find an option to make "ls" display the real size for directories...all directories are displayed to be 4,0K
as in this example (I use ls -Alh --color):
drwxr-xr-x 2 johnjohn defaut 4,0K 2008-04-30 22:26 directory1

Any idea?
Thanks

jailbait · 04-30-2008, 04:15 PM

I am unsure of your definition of the real size of a directory. What ls shows is the size of the directory entry. If by "real size" you mean the total size of all of the files in a directory then use the du command. For example if you want the total size of /home/user/data and all of its contents use:

du -h --max-depth=1 /home/user/data

See:

man du

---------------
Steve Stites

forrestt · 04-30-2008, 04:16 PM

The ls command is not telling you the total size of all the files and subdirectories inside the directory. It is telling you the the amount of bytes it needs to define the files/subdirectories that it contains. It just appears that all directories are 4,0K because that is the default size of a new directory. When you come across a directory with a whole bunch of files, you will see that the number does in fact go up. To see the total size of all the files and subdirectories of a directory, you use "du -s directory".

HTH

Forrest

louisJ · 05-01-2008, 01:42 AM

thank you,

"du -s directory" actually gives the size I need.
But I am looking for a way to get directly by typing a unique command, the sizes, names, and other details of both files and directories total content....
Is it possible to pass the result of "du -s directory" to ls?

forrestt · 05-01-2008, 09:15 AM

You can't pass du -s to ls, it would try to find a file that is named the size that du returned. However, you could write a script that calls ls and then loops through all the listings and if it is a directory (first letter of line is a d) then run du on the name for that field and spit it out as one line. I'm not aware of a command that will do that. Perhaps someone else?

Forrest

colucix · 05-01-2008, 10:01 AM

Following the suggestion from forrestt, you can define a shell function like this, using awk to parse the output of ls -l:

Code:

function lsd () {
ls -l | gawk '
   substr($1,1,1)=="d"{
      ("du -bs " $NF) | getline size
      split(size,size_)
      sub($5,size_[1],$5)
   }
   { printf "%s %2s %s %s %10s %s %s %s %s\n",$1,$2,$3,$4,$5,$6,$7,$8,$9}'
}

then every time you type "lsd" a long listing is produced with the size of directories substituted by the total size of their content.

forrestt · 05-01-2008, 10:10 AM

colucix, you couldn't have picked a better name

. I love it.

Forrest

louisJ · 05-02-2008, 01:37 AM

hi colucix

thank you for this suggestion.

I pasted this function definition in my bash prompt
ans tested it
but it seems there is an error when I type lsd:
$ lsd
total 839K
-rw------- 1 louisJ None 71K May 2 08:16 .bash_history
-rwxr-xr-x 1 louisJ None 1.2K Jun 11 2007 .bash_profile
du: can't access `\033[01': No such file or directory
sh: $'34mJC\E[0m': command not found
drwx------+ 2 louisJ None May 2 08:34 JC

I am new at this, any idea where the problem is?
Thank you

colucix · 05-02-2008, 02:03 AM

Quote:

Originally Posted by louisJ

du: can't access `\033[01': No such file or directory
sh: $'34mJC\E[0m': command not found

Hmmm... I don't know where these strange characters come from. They seem some terminal color codes. Please, try to write the function by typing it... without copy/paste.

newtovanilla · 05-02-2008, 02:27 AM

Quote:

The ls command is not telling you the total size of all the files and subdirectories inside the directory. It is telling you the the amount of bytes it needs to define the files/subdirectories that it contains. It just appears that all directories are 4,0K because that is the default size of a new directory.

The ls command shows me what looks to me to be the sizes of files in the directory that I am in when I enter the command. Are these not the real sizes of those files?

Also, I went used the mouse to click on the "home" icon on the desktop of kde 3.5, and I can browse for the directory that I want to size. I can select that directory and right click with the mouse and select "properties" and it will show me the size of that directory.

1) There is something that I do not understand about that "size" utility in that it calculates the size of the directory, but sometimes the size does not seem to be the right size. For example, when I tried to find out how much harddrive space was left on my harddrive, I went to "Storage Media" and did the properties on it. Something seems wrong with the size that it displays for the harddrives. It says that 11GB are used, but it also says beneath that there is 21GB free of 30GB. If I add 11+21=32GB, I get an extra 2GB. Is there something that I do not know about?

forrestt · 05-02-2008, 09:35 AM

newtovanilla,

The ls command will tell you the size of the individual files inside the directory. It won't tell you the TOTAL size of all the files and subdirectories inside the directory. So, if a directory is able to define all of its contents with only 4K, it will read 4K. If it needs more bytes to define the contents, it will allocate more space for its size description in 4K blocks. Files DO state the amount of space they take up. Directories do not.

As for your follow up question, the only thing I can think of is that it might be rounding things somehow. If I do the same thing on one of my storage media folders, it tells me I'm using about 25% of my drive. However, the df command tells me I'm really only using 21%. I believe df over the other.

HTH

Forrest

ararus · 05-02-2008, 10:21 AM

This discussion is flawed. The ONLY space a directory takes up is the space required to hold the directory entries. To talk about the "size" of the directory in the context of "the size of all the files/directories under it" makes no sense (remember that files can be hard-linked in different directories).

It's very important to bear in mind that files are not "contained" in directories. This is one of the things that always irritates me about Windows etc using terms like "folders". A folder gives the impression of a *container*, i.e. you can put things in it. In unix, a directory is NOT a container, it has no size other than the directory entries. Think of a directory tree more as an index or database, to tell you where to find your data (just as the Dewey Decimal system indicates what shelf to look on to find a book in the library, a directory entry tells you (or rather the kernel) what inode to look at to find your file).

Quote:

Originally Posted by forrestt

As for your follow up question, the only thing I can think of is that it might be rounding things somehow.

This is almost certainly the case. newtovanilla, you probably do not have 11GB, it is probably 10 and a bit. Likewise the free space is probably 20 and a bit, you're filesystem probably isn't _exactly_ 30GB, most likely a few MB this way or that way. When you take this into account, it all adds up. Unless/until your filesystem is 99% full, I wouldn't worry about a few percent discrepancy.

forrestt · 05-02-2008, 12:00 PM

I don't have any problem with someone conceptualizing a directory as a container. We are humans, and this is how we think, and to know how much stuff is in a container is a useful piece of knowledge (if it weren't we wouldn't have the du command). Thinking of directories as containers makes things easier to visualize and keep track of things in our minds. It may not be the way the file-system actually works, but it is how most people think, and makes perfect sense whether you have hard links or not. To visualize a directory as a database could only be useful if you are someone who is actually designing or programming a file-system. For anyone else, to do so is making things way more complicated than they need to be. If someone knows what the size entry in ls means for a directory entry, then they're fine. But, if they don't, then it needs to be explained, because the natural way of thinking is to assume it means something that it does not. It isn't the conceptualizing that is wrong. It is the assumption that a particular tool is giving one piece of information, when it is actually giving another piece, that is wrong. That is fixed by teaching others how to use our tools.

My 2 pennies,

Forrest

colucix · 05-03-2008, 03:55 AM

What a directory really is, can be better visualized by issuing

Code:

vi directory_name

the directory is opened as any other file, even if it is treated by vi in a different way.

Tinkster · 05-03-2008, 04:21 AM

Quote:

Originally Posted by forrestt

I don't have any problem with someone conceptualizing a directory as a container. We are humans, and this is how we think, and to know how much stuff is in a container is a useful piece of knowledge (if it weren't we wouldn't have the du command). Thinking of directories as containers makes things easier to visualize and keep track of things in our minds. It may not be the way the file-system actually works, but it is how most people think, and makes perfect sense whether you have hard links or not.

Way over-thought. Just compare a directory in a Linux
file-system to a phone directory. It points to what you're
after in an organised way. To say it "contains" those entries
is at best a matter of (flawed) semantics - you wouldn't say
a phone directory has people's phones; it points at them.

Cheers,
Tink