* 'master' of git://github.com/paulharris/nocache:
  Adjusted script so it will preload the .so from the script's directory

Thanks again, kocmo, for noticing.

Thanks to kocmo for the patch.

man pages

* test:
  Add "ls" test
  Make it easy to add new tests
  Add make target “test”
  Add very basic test

This issue came up in the real world because apparently
libselinux.so.1 does an fopen in a constructor function.
Big Thanks to Mike Shal (http://sourceware.org/ml/libc-help/2009-06/msg00000.html )

[Made some cosmetic changes -JP]

Fixes: GitHub issues #1 and #2
Signed-off-by: Julius Plenz <julius@plenz.com>

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.