[PLUG] Moving gdbm files from 6.2ish to 9.0

[Zot O'Connor]

On Fri, 2003-10-17 at 16:58, Jeme A Brelin wrote:
> On Fri, 17 Oct 2003, Zot O'Connor wrote:
> > I am having some issue moving some gdbm file from an old rehdat 6.2 box
> > to 9.  It seems that gdbm has changed?
> 
> Undoubtedly.
> 
> > Is there a conversion program?  This is highly annoying.
> 
> I don't really use gdbm much, but couldn't you write your own sort of fake
> conversion program where you read the db files with a tool on a box using
> the old gdbm library and dumped it into another data format (like a perl
> object dumped with Storable or Data::Dumper or whatever) and then read the
> data back in on the other machine and output it to a db file?

Yeah, that what I am trying to avoid doing :)  I have a bunch of silly
support files for a system and convert each one is time consuming and
likely to cause problems.  

It is really annoying that this happens,  I am betting on a RH9/gcc
issue again.  I mean why did anything change to a file format?  I am
guessing its a lib call issue (several programs are showing the same
behavior, the latest is PHP).

  Looking at gnu (and do not get me started with finding useful
information on gnu tools):

/usr/share/doc/gdbm-1.8.0/NEWS

CHANGES from 1.7.3 to 1.8
  1.  Added GDBM_CENTFREE functionality and option.
  2.  Added GDBM_COALESCEBLKS functionality and option.
  3.  Added GDBM_NOLOCK flag.
  4.  Made ``fast'' mode the default, making GDBM_FAST obsolete, and
adding
      the GDBM_SYNC flag and GDBM_SYNCMODE option.
  5.  Switched to building with libtool.

CHANGES from 1.7.2 to 1.7.3
  1.  Fixed a couple of last minute problems. (Namely, no autoconf.h in
      version.c, and no GDBM_FASTMODE in gdbm.h!)
  2.  Fixed some documentation bugs.

None of these should effect format issues.

> 
> I know that's a hack, but without being intimately familiar with the
> internals, that's how I'd do it.
> 
> J.
-- 
Zot O'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com