Calls to open() from within glibc cannot be intercepted
(see <http://cygwin.com/ml/libc-alpha/2006-04/msg00094.html>);
thus, include wrappers for fopen() and fclose() as well.

This should possibly be done for fdopen() and freopen(),
too, if there's need for it.

[Patch corrected and original description translated by Julius Plenz]
Signed-off-by: Julius Plenz <plenz@cis.fu-berlin.de>

When you invoke "tar cfv <tarball> <files>", then tar will close all
active file descriptors it has, forks, then opens the target tarball
as fd 1 (stdout). Then, it'll exec "gzip -", which *inherits* a stdout
which is a file.

Now we duplicate this stdout if it's a regular file so that we can
advise it later. (The original will be closed via the _exit() routine,
probably, which uses direct syscall that we cannot intercept.)

Thus, also shell redirection -- which makes heavy use of dup2() --  is handled
correctly:

    $ cachestats /tmp/foo
    open: No such file or directory
    $ nocache sh -c 'echo foo > /tmp/foo'
    $ cachestats /tmp/foo
    pages in cache: 0/1 (0.0%)  [filesize=0.0K, pagesize=4K]

* tar-quirks:
  Add an alias __openat_2() for openat()
  intercept creat()

Don't ask me for the reason why a straight-forward openat() call in
GNU tar ends up calling __openat_2() via the glibc. I don't know.
Anyway, that's the first time I had to ask something on StackOverflow,
and I was promptly pointed in the right direction!
<http://stackoverflow.com/questions/9161116/intercepting-the-openat-system-call-for-gnu-tar>

Still, there is some sort of racing condition I cannot reliably
reproduce, but often enough observe. It looks like this:

    $ ./cachedel z && ./nocache cat z > /dev/null && ./cachestats -v z
    pages in cache: 2/16 (12.5%)  [filesize=64.0K, pagesize=4K]

    cache map:
         0: | | | | | | | | | | | | | | |x|x|

Although of course the file should not be cached at all.

Also, fadv_dontneed will do the double syscall now.

There is a promising patch that adds POSIX_FADV_NOREUSE heuristics, see
http://article.gmane.org/gmane.linux.kernel.mm/65564

    > This will mean that there is no way currently to
    > remove a particular file from the cache on linux.

    Correct. There's not a way to do this for a single file (except running
    POSIX_FADV_DONTNEED twice...).

If only one fadvise64 syscall is performed, the *first* previously
unsused page will somehow not be forgotten.

The kernel tries once to lock the page to be freed. If this fails, it won't be
freed. (This happens quite often, actually!)

The strange thing is that subsequent calls will eventually fill the
cache, bit by bit. (This is in the dimension of n < 10 pages per call.
But still I can't figure out where this happens.)