The method OLEDate2Local() converts a windows Filetime time into a posix date array (struct tm-like). It may be called with a date argument 0 which is an unset windows file time. Now, the method OLEDate2Local() internally converts a 0 file time into a now meaningless negative posix time_t-like value. Going on using this value on on windows, by chance this always results in an undef return value as gmtime() rejects this value. At least on my Linux system, this time_t-like value is accepted and the result is NOT undef. This leads to errors in subsequent modules. Here is a fix: --- /usr/share/perl5/OLE/Storage_Lite.bak 2009-09-04 12:08:30.000000000 +0100 +++ /usr/share/perl5/OLE/Storage_Lite.pm 2009-09-04 17:11:52.000000000 +0100 @@ -1328,6 +1328,9 @@ # Unpack the FILETIME into high and low longs. my ( $lo, $hi ) = unpack 'V2', $oletime; + # No date defined + return undef unless $lo && $hi ; + # Convert the longs to a double. my $nanoseconds = $hi * 2**32 + $lo; Kind regards Jordan
Bug #49479 for OLE-Storage_Lite: OLEDate2Local() bug with 0 datetime
This queue is for tickets about the OLE-Storage_Lite CPAN distribution.
Nobody in particular
jordan.hrycaj [...] 7safe.com