Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Andrew P J. <mdb...@an...>]

On Thu, 2013-05-02 at 18:02 +0200, Alexander Lehner wrote:
> 
> On Thu, 2 May 2013, Andrew P Jones wrote:
> 
> > Apologies in advance: I haven't written any c for 10 years so although I
> > believe I have identified the bug I have not yet succeeded in building /
> > testing a fix.  Configure tells me I need glib2 but that is a different
> > issue.
> >
> > The meat of this mail is also on the linux mint forum as I am not sure
> > if the problem is packaging or mdbtools itself
> >
> > http://forums.linuxmint.com/viewtopic.php?f=47&t=132702
> >
> > The problem is that in src/libmdb/file.c  mdb_find_file() fails if
> > stat(Filename, &status) fails.
> >
> > Broadly speaking, the Windows server returns a 64 bit stat structure
> > which exceeds the length of the 32-bit stat structure allocated on the
> > linux box and causes stat() to fail.
> >
> > The above sentence was both inaccurate and garbled - a much better
> > explanation can be found here:
> >
> > https://bugzilla.samba.org/show_bug.cgi?id=7707#c1
> >
> > The above link recommends building with:
> >
> > -D_FILE_OFFSET_BITS=64
> >
> > I did wonder if it would be cleaner to change
> >   struct stat status;
> > to use a GStatBuf  and use the corresponding g_stat () call, but if I
> > have understood this page correctly...
> > https://developer.gnome.org/glib/2.35/glib-File-Utilities.html#GStatBuf
> > ... that will continue to use a 32 bit structure.
> >
> > Sorry if this reads like "Here's your problem - go fix it."  I have
> > tried several times to build the code downloaded from sourceforge
> > without success.  If anyone has seen and worked around the error below
> > and can tell me how to without breaking the linux Mint box which I am
> > accessing remotely I will gladly experiment further.
> >
> > checking for GLIB - version >= 2.0.0... no
> > *** Could not run GLIB test program, checking why...
> > *** The test program failed to compile or link. See the file config.log
> > for the
> > *** exact error that occured. This usually means GLIB is incorrectly
> > installed.
> >
> > glib 2.0 is required by MDB Tools.
> > It can be downloaded at www.gtk.org.
> >
> 
> Not quite sure whether I understand your problems:
> 
> You seem to have a working binary of libmdb but that one only supports 32 
> bit.
> You want to build it on your own for 64 bit.
> 
I have a working installation of mdbtools installed from its package by
apt on 32 bit Linux mint.

However mdbtools tests for the presence of the database before opening
it.  The way it tests is unreliable when using a Microsoft Access
database hosted on a Windows server.

The best information I can find to explain this unreliability is here:

https://bugzilla.samba.org/show_bug.cgi?id=7707
"Short answer: You need to recompile your test program with 

    -D_FILE_OFFSET_BITS=64

What's happening is that glibc uses the stat64() system call to handle
the stat, even with 32-bit non LFS programs. When it gets back a large
inode number that doesn't fit in a 32-bit value, it generates EOVERFLOW
in userspace and returns that to the program."


...And from Wikipedia
https://en.wikipedia.org/wiki/Stat_%28system_call%29
"The family of functions was extended to implement large file support.
Functions named stat64(), lstat64() and fstat64() return attributes in a
struct stat64 structure, which represents file sizes with a 64-bit type,
allowing the functions to work on files 2 GiB and larger. When the
_FILE_OFFSET_BITS macro is defined to 64, these 64-bit functions are
available under the original names."

I would like to be able to build the application from source so I can
test if the above is true and if it breaks mdbtools for local files.

Finally, if I run  stat <filename> from a terminal prompt the result
displays with no apparent error and the inode number has 17 digits.  So
I know the computer is capable of handling it but mdbtools is not.

> The build failed due to the missing glib installation.
> 
I thought I had glib installed correctly.  I was wrong.  After
reinstalling it configure appears to work correctly.

Now make fails...


> If you don't want to install glib (no idea what dependencies that pulls 
> in, but I guess you will not screw up your machine with that):
> 
> I had to build libmdb without glib for myself. What I did was replacing 
> the few glib functions beeing used by my own implementation.
> That were mostly some hash tables which I replaced by simply using the 
> STL, so it is no longer plain C code.
> 
> Also, that step requires some knowledge of autobuild, or you compile and 
> link the libmdb sources for yourself, which is not such big trouble.
> 
> If that helps, I can share my code.
> 
Thanks for your response, but all I want to do is to get a basic
standard version running.  

make fails like this:

 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -g
-O2 -DSQL -MT backend.lo -MD -MP -MF .deps/backend.Tpo -c backend.c
-fPIC -DPIC -o .libs/backend.o
backend.c:31:20: error: static declaration of 'mdb_backends' follows
non-static declaration
../../include/mdbtools.h:150:20: note: previous declaration of
'mdb_backends' was here
make[2]: *** [backend.lo] Error 1
make[2]: Leaving directory
`/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src/libmdb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src'
make: *** [all-recursive] Error 1

Could anyone offer any suggestions?

Thanks again
Andy

> Alex.