I need a program to find the size of a directory.. When i tried to get the size, it always gives the default space allocated for it. How can i findout the exact size of a directory using a c program
YEah, right about fts... Wasn't sure if this could be standard or not. But AFAIK, Linux has it too.
But there is no significant overhead with du... This definitively is I/O bound. The biggest problem is that this is prolly only there on UNIX systems. And now that I think about it... du/fts will probably be optimized to run much faster than whatever could be coded trivially... Heh, what overhead? Not to mention du/fts will probably get right the traversing of the hierarchy while it is being modified. Modularity.
If you mean that there is a portability issue with du, I agree with that. But spawning the sub-process will take almost no time compared to reading the directories. The overhead will never be noticeable.
1) AFAIK, it keeps opened FDs to the parent directories as it does the traversal. If some directories are moved, it will always use the right parent dir. There might be other stuff they did in fts as IIRC, there were security issues related with that as rm -r, chmod -R, find, etc, are often using fts and could be used as root on user files (ex, what happens if root does rm -rf ~user/stuff and user moves ~/stuff/a/b/c to /tmp while rm is traversing it? if using chdir ".." without checking if the parent dir is the same, it could end up traversing files starting at /. If not using "..", it will not traverse all the files in ~user/stuff because the path have changed. Keeping the open'd FD requires keeping them in dynamic data structures and this is a waste of time to code again).
2) ... Dude... It Is BECAUSE this is I/O bound that adding some CPU overhead to reduce the I/O will give a faster results. You see for yourself; they have a lot of code in that library and this is prolly not to make things slower (although a lot of it could be for security): http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fts.c
It can still be much more accurate using a du that uses fts. Ex, it should be harder to make the program sum up everything in / erroneously.
Heh. That's something that puzzles me about most textbook algorithms too, dude. But this is definitively possible to reduce I/O while adding some CPU overhead; think of the tree/hash used databases....
Most fts should be similar, if not better (especially considering that this one is very old and really free (so it could have been forked a few times)). Just consider this one a proof of concept if you want...