Description of problem: The boost::serialization is meant to produce files which can be read by later versions of itself. Unfortunately there was an incompatibility introduced in boost 1.44 which disallows it from reading old files. See: https://svn.boost.org/trac/boost/ticket/4660 From that thread it is not entirely obvious where in the two patches 66106 and 66107 the problem is addressed. Apparently boost 1.45 will work as expected (read files created with 1.3x, 1.41, 1.42, 1.43 and write in the 1.45 format). Version-Release number of selected component (if applicable): 1.44 How reproducible: Seems every time. Steps to Reproduce: 1. make a text or binary file in Fedora 13 and try to unserialize it in Fedora 14 boost-1.44.0-7.fc14.x86_64 and you get either: binary archive terminate called after throwing an instance of 'boost::archive::archive_exception' what(): invalid signature txt archive terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unsupported version Actual results: Shown above. Expected results: Program should read the serialized data and continue execution instead of terminating. See cser / tser for example programs to make and read serialized data. Additional info: I tried to find this bug assuming it would exist, apologies if I missed it.
Created attachment 490554 [details] Candidate fix The two commits that upstream lists seem to be mostly formatting changes, and then there's one commit somewhere (it's not referenced in the bug report) that also fixes some sort of issue. What I'm attaching instead is cut-down version of merge commit that I got from boost git. I haven't yet tried to do anything with that patch.
Rebuilding boost-1.44.0-7 with this patch included gives me the following error: in binary archive: terminate called after throwing an instance of 'boost::archive::archive_exception' what(): incompatible native format - size of int IIRC for the binary archive there was talk about going from 8 to 16 bits for the version number.
(In reply to comment #0) > Apparently boost 1.45 will work as expected It doesn't seem to. Or at least 1.46 that we have in F15 is unable to read archives created by 1.41 that we have in F13.
Created attachment 509580 [details] Fix This augments attachment 490554 [details] that I posted earlier. Here where I'm sitting, version 6 archives have only one byte of version information, which means we should handle it the same way as version <6. That's what this patch does. I tested this with boost 1.46 and it fixes the issue. This whole "compatibility" scheme fails for two-byte versions where the first byte happens to be 0x01 again, but hopefully such deep backward compatibility won't be necessary by that time. Thinking about it some more, I wonder why they handle it the way they do. How comes that if it starts with 0x06, it's always two bytes, and when it starts with 0x07, it's two bytes only if followed by zero? Hopefully it's just a mistake. Fortunately we know that there are more book-keeping data coming after the version, and that 0x00 is always part of version information and never the book-keeping. I'll have to pass this patch by upstream, I have no idea how the format evolved historically.
Ah, never mind the std::cout bit, that's an artifact of debbuging ;)
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping