This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: exim and gdbm

Pierre A. Humblet wrote:
> Corinna Vinschen wrote:
>>On Thu, Jul 17, 2003 at 09:48:28PM -0400, Pierre A. Humblet wrote:
>>>Bad news:
>>>The new gdbm library can't open old gdbm files because
>>>an internal structure has changed size.


I did not realize that.  I've withdrawn gdbm until we have a mechanism to
convert "old" databases to "new".  Does anybody know of a "gdbm to
<platform independent>" database dumper (and reader!), so I don't have to
write one myself?

>>>Good news (at least for exim users):
>>>Exim keeps no essential info in its db files.
>>>All files in /var/spool/exim/db should be deleted when
>>>installing the new gdbm.

But that is certainly not true in general.  Exim may be lucky -- and cvs
(which uses gdbm) may also be lucky -- in the sense that the database
files are intended to be ephemeral, or are backed by plaintext files
(modules vs. modules.db)  But not every gdbm user will be able to blow
away their files.

>>Wouldn't it make sense to add that to the postinstall script?  This
>>might get rid of a couple of "Exim 1.5.0 not work"  questions on the ML.

> Good idea. But how can I detect if it's the first time?
> Also, people might jump from 4.20-1 to a future 4.X-Y
> Ah, the postinstall script could try to gdbm_open the files
> and delete them on failure (e.g. using /bin/exim_dumpdb). 
> Strictly speaking it should be in the gdbm postinstall.

Hell no.  How would I know which files to delete?  For every possible use
of gdbm?  This is first I've heard of gdbm being used by exim; I knew
about perl and cvs.  Tomorrow when package "foo" gets added to the cygwin
distribution, *I* am required to update my gdbm package to take care of
foo.db?  Ain't happening.

Should gcc search your entire disk for .o files, and delete them when gcc
is upgraded?  The old .o's may not be compatible with the new gcc, after

> Not sure how far I want to go. The databases basically contain
> optimization hints. Exim keeps going when it can't open them, simply
> making a log entry. I need to think some more.

We just need a conversion tool.

As I said, gdbm is withdrawn.  When I re-release a 64bit version, I'll
bump the DLL version.  That way, existing programs will continue to use
the old cyggdbm.

Plus, with some luck or help, I can write a program that dumps a database
to an interchange format.  executable #1 is linked to the old gdbm dll,
and is used to write the database out to interchange format.  executable
#2 is linked to the new gdbm dll, and is used to read the interchange
format in, and save out to a new gdbm file.

It's also possible that executable #1 should be compiled on a stock
cygwin-1.3.22 system...

  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]