I have found that due to the way the macro definitions are used in the glibc header files, it is not possible to know the size of structures that was used in an independently-compiled application. libsmbclient, similarly, futzes with internal macros to force the glibc definitions into mapping 32-bit functions into 64-bit functions.
As an example, I found cases where sizeof(struct stat) was different in the calling application (ps in my test case) than it was in smbwrapper and libsmbclient. At least with the glibc environment, I found the paradigm used for smbwrapper to be insufficient to handle the variety of applications that may be wrapped. I have therefore mostly completed a rewrite of the outer layer of the wrapper functions using a new paradigm. In my new paradigm, we do not attempt to "fake" the C library by using internal functions or directly calling system calls. Instead, we use dlsym() to find the real function pointers in the C library. If the call is pertaining to a native file descriptor, the functions in the C library are called directly. If the call is for an SMB file descriptor, then the smbw_ functions are called. The wrapper functions are able to fully define the function interface by including the native system header files rather than masking the real functions (e.g. with void* and arrays of doubles in place of stat structures). Additionally, to avoid the problems with varying sizes of structures due to our lack of knowledge of how the child application was compiled, I am creating internal structures for interaction between the wrapper function and the smbw_ functions. The interface between these layers will be with the known internal structure, and I will then do a field-by-field assignment between them. (Yes, this is a bit slower, but it's primarily for the stat() family of functions which are not typically high-frequency calls, and the alternate memcpy method just can't work in this environment.) The other issue I'm facing is with some of the 64-bit calls -- and my lack of knowledge about SMB/CIFS protocols. Are 64-bit offsets into files possible in the SMB/CIFS environment? Are there file systems (e.g. NTFS?) that support files larger than sizes that will fit in 32 bits? The current implementation of pread() for example, passes an "off_t" which may be 32 bits or may in fact be remapped as an "off64_t" based on the defines passed to the compiler. So my questions are: 1. Are there LFS requirements for SMB/CIFS or can I just drop the high-order portion of 64-bit file offsets? 2. Does anyone anticipate any particular problems with the implementation I have described? (It's currently working for native file access, with all applications that I've tried -- including those that previously did not work, such as the Debian binary of bash, and ps. My testing has not been exhaustive, though, so if there are particular areas that I should test or watch out for, I'd like to know.) Thanks! Derrell
