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

[Andrew P Jones]

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.

Thanks and best regards,

Andrew Jones

BTW - Thanks for the great application. Where do I send the postcard?

[Alexander Lehner]

Post by Andrew P Jones
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
https://bugzilla.samba.org/show_bug.cgi?id=7707#c1
-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.

The build failed due to the missing glib installation.

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.

Alex.

[Andrew P Jones]

Post by Alexander Lehner

Post by Andrew P Jones
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
https://bugzilla.samba.org/show_bug.cgi?id=7707#c1
-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.

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.

Post by Alexander Lehner
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...

Post by Alexander Lehner
If you don't want to install glib (no idea what dependencies that pulls
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

Post by Alexander Lehner
Alex.

[Alexander Lehner]

Post by Andrew P Jones
[...]
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.
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.

Post by Alexander Lehner
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...
[...]
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?

What version of libmdb are you using?
What says 'gcc --version'?

I just downloaded mdbtools 0.5 release and 'make' was successful.

It seems that the line numbers compared to your error message do not
match to the sources I've got.

I understand what the error message says and am wondering how such code
could become an official release. As far as I understand, such
construction never will compile.


Alex.

[Andrew P Jones]

Post by Alexander Lehner
What version of libmdb are you using?
What says 'gcc --version'?

I extracted the files from mdbtools-0.6pre1.tar.gz

downloaded from http://sourceforge.net/projects/mdbtools/files/

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

The packaged version of mdbtools currently installed and 'working' is

$ aptitude show mdbtools
Package: mdbtools
State: installed
Automatically installed: no
Version: 0.5.99.0.6pre1.0.20051109-7.1
Priority: optional
Section: utils
Maintainer: Ubuntu Developers <ubuntu-devel-***@lists.ubuntu.com>
Uncompressed Size: 233 k
Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.12.0), libmdbtools (>=
0.5.99.0.6pre1.0.20051109), libreadline6 (>= 6.0)
Description: JET / MS Access database (MDB) tools
These are various tools for manipulating JET / MS Access database (MDB)
files:
* utils - provides command line utilities to list tables, export
schema,
and data, show file versions, and other useful stuff.
* mdb-sql - a command line SQL tool that allows one to type sql
queries and
get results.
* odbc - An ODBC driver for use with unixODBC driver manager.
Allows
one to use MDB files with PHP for example.
Homepage: http://sourceforge.net/projects/mdbtools/

Post by Alexander Lehner
I just downloaded mdbtools 0.5 release and 'make' was successful.
It seems that the line numbers compared to your error message do not
match to the sources I've got.
I understand what the error message says and am wondering how such code
could become an official release. As far as I understand, such
construction never will compile.
Alex.

I will download and try version 0.5 tomorrow.

Thanks for your help,

Andy

[Alexander Lehner]

Post by Andrew P Jones
[...}
I extracted the files from mdbtools-0.6pre1.tar.gz
downloaded from http://sourceforge.net/projects/mdbtools/files/

OK, that's it. I can get the compile error with 6pre1 as well.

#####
Hack the source:

include/mdbtools.h, line 150, remove these lines:

/* hash to store registered backends */
extern GHashTable *mdb_backends;

#####

There's no need to declare mdb_backends as global variable any longer, and
in fact it isn't one.

In 0.5 there was a reference to mdb_backends from mem.c, but it's
implementation now seems to have moved to backend.c, which is fine.


I'm just wondering why nobody else had this problem before?
I'm not a real mdbtools developer, just tracking this list. Is there a way
to report this problem?
Won't actually dare to mess in the sources...

Alex.

[Jean-Michel Vourgère]

Hi

I still did not dig in your problem yet.

But you'd better take last version 0.7 from github:
https://github.com/brianb/mdbtools

Cheers

[Nirgal]

Post by Alexander Lehner
I understand what the error message says and am wondering how such code
could become an official release. As far as I understand, such
construction never will compile.

Actually, it depends on the compiler version.
See http://gcc.gnu.org/ml/gcc-bugs/2004-12/msg00415.html

[Nirgal]

Post by Andrew P Jones
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
Could anyone offer any suggestions?

Fixed since version 0.7