Re: [Boost-users] [serialization]Runtime Exception While Loading Old Serialized XML Files w/ 1.38

Subject: Re: [Boost-users] [serialization]Runtime Exception While Loading Old Serialized XML Files w/ 1.38
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-25 12:31:20

First of all, any failure to read any archive created under a previous
version of the library is a bug.  Thanks for pointing this out.

This is likely fixable, but we would need a little more information.

a) I'm not sure what version 4 and version 5 refers to - expand upon this.
b) I'm not sure what type the "item_version" refers to. Is it the list type 
or
(more likely) the type which is being pointed to.
c) what type is being pointed to?
d) can we assume no changes in the serialization traits?

Robert Ramey

Hello list,

I have a bunch of XML files that have been serialized using
Boost.Serialization (the standard XML archive) and were working fine
until we upgraded to the boost trunk a few days ago (unfortunately, I
can't tell exactly what repository revision were used to generate the
archives, but I know they were custom builds of pre-release 1.37 trunk,
and the file_version attribute in the XML is set to 4.) Also, we use
MSVC9.0sp1 for building everything.

As soon as we upgraded to the trunk, we started getting runtime
exceptions (invalid archive format) on some of our larger files. I think
I have tracked it down to an incompatibility between version 4 and
version 5 files that the newer build fails to take into consideration,
the details of which (as far as I could find out) follows.

In our data structures there is an std::list of pointers to objects
previously serialized in the same serialization operation (which means
these repeated pointers are stored as a reference to the previous object
and the data is not duplicated.) Using the old library, when this list
was being serialized, apparently the "item_version" was not being
written (only the "count" filed and the "item"s were.) The old library
apparently didn't expect to read this either, so everything worked out
nicely. The new library however, expects an "item_version" field and
throws when it doesn't find one.

As I trace into the serialization library, I can see that there is logic
there for new libraries to be able to handle archive format changes
through time. Now my question is whether this "discrepancy" is actually
a bug in either the older or the new code, or failing to handle the
format change is a bug, or this issue has already come up and been dealt
with in some other way? (how?)

I should also mention that it is quite probably that the problem be in
our code, but I have no idea how. I would appreciate any help in
locating it.

Any pointers, help, clues and general wisdom is greatly appreciated.

-yzt