|
Posted by John Bokma on August 7, 2006, 1:49 am
Please log in for more thread options
austinke@yahoo.com wrote:
> If I store something from one of the newer boxes, and then try to thaw
> it from an older box, I get the following error:
>
> Storable binary image v2.6 more recent than I am (v1.0) at
> blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al)
> line 238
[..]
> I tried looking through the new version of Storable's documentation to
> see if there's a way to save it in a Storable.pm version 0.6.1.11
> format, and didn't have any luck there.
Weird, I found this in just a few seconds:
"nothing in the Storable file header reflected whether the perl writing
was using 32 or 64 bit integers, despite the fact that Storable was
storing some data differently in the file. Hence Storable running on perl
with 64 bit integers will read the header from a file written by a 32 bit
perl, not realise that the data is actually in a subtly incompatible
format, and then go horribly wrong (possibly crashing) if it encountered a
stored integer. This is a design failure.
Storable has now been changed to write out and read in a file header with
information about the size of integers. It's impossible to detect whether
an old file being read in was written with 32 or 64 bit integers (they
have the same header) so it's impossible to automatically switch to a
correct backwards compatibility mode. Hence this Storable defaults to the
new, correct behaviour.
What this means is that if you have data written by Storable 1.x running
on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux
then by default this Storable will refuse to read it, giving the error
Byte order is not compatible. If you have such data then you you should
set $Storable::interwork_56_64bit to a true value to make this Storable
read and write files with the old header. You should also migrate your
data, or any older perl you are communicating with, to this current
version of Storable."
From the above I would suggest migrating instead of module hacking. It
might cost you time now, but saves you a load later.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
|