Quote:
Originally posted by Driver
> This definitively is I/O bound.
Irrelevant. Invoking an external program adds the time needed to create a process, execute the du program, communicate back the results and destroy the process. Whether this is going to be a problem or not depends on the application; And a portable directory traverser, once written, will compile even using only, say, DOS/Windows libraries - with minimal changes (many libraries provide the exact same functions prefixed with a ``_'' character, and/or declared in a header called direct.h instead of dirent.h)
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.
Quote:
> 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.
In think that you are dreaming this up in order to support your assertion that ``du'' is a superior solution
If you can explain how a program can ``get right the traversing of the hierarchy while it is being modified'' (and what you actually mean by that), I'm all ears. As to whether it will be ``optimized to run much faster'', well, there's not a lot of room for any relevant differences. In part because it is ``I/O bound'', as you said earlier.
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.cg...libc/gen/fts.c