smbwrapper/smbsh on Linux/glibc

[Derrell.Lipman at UnwiredUniverse.com]

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