Date: Thu, 27 Apr 2006 12:55:28 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: libc-alpha@sourceware.org Subject: fopen() calls __open() Message-ID: MIME-Version: 1.0 Hi all, I'm on the Samba team, responsible for the client library, which provides Unix/Linux access to Windows networks. As an example program for using that library, I have an LD_PRELOAD library that traps primitive file system calls and if the path is to /smb/... it maps to the Samba client library; otherwise to RTLD_NEXT (glibc). This all works great for most programs. For the primitives that are mapped, three versions of each are mapped: 0, 1 and 2 leading underscores (if such functions actually exist in the C library). For example, I map open, _open and __open (assuming they exist in the library). The problem is that some internal non-primitive functions like fopen() directly call __open(), and (from my read of the source, it appears that) __open() is aliased to open() such that fopen()'s call to __open() isn't trapped by my preload library. This means that if the file /smb/SERVER/SHARE/filename is open()ed, the file on the remote Windows server gets properly opened, but if that same file is fopen()ed, no file is found because the internal __open is called. I know that I could override fopen() and friends (including any other "high- level" functions that call internal versions of primitive functions), but there's a fair amount of code involved in those, and reimplementing or copying them for the sole purpose of compiling them such that they use the overridden open() call seems a lot like overkill. What can I do to cause fopen() in glibc to call the open() or _open() or __open() in the preload instead of the internal __open? Thanks in advance for your help! Derrell