Thanks Nick, I've only got a single file that shows the problem, the suggested patch makes this email parse correctly and allows existing tests to run. I tried to follow the existing style of tests, but I'm not sure how to create test data that transitions the year around the change-over date.
I've been reading the HSMF source + MSG file specifications. If I've understood the basic format correctly (leaving to one side the various recipient and attachment tables): 1) *all* properties are accessed via the "__properties_version1.0" file 2) fixed length properties are entirely contained in this file 3) variable length and array properties are read from various "__substg1.0_" prefixed files So I'd guess from your comment that the "__properties_version1.0" file isn't being properly handled at present. Does that sound right? I note that PropertiesChunk.java exists and attempts to parse this file. Is this where you think the problem lies? All very interesting! Adrian -----Original Message----- From: Nick Burch [mailto:[email protected]] Sent: 18 March 2015 18:06 To: POI Developers List Subject: RE: Bugzilla item #57678 (Incorrect year parsing in message submission chunk) On Wed, 18 Mar 2015, Adrian Conlon wrote: > WRT test files, there's a test file associated with the bugzilla > entry, did you mean something more targeted than this? We really want a files with a value of 69, 70 and 71, showing a mapping to 2069, 1970 and 1971 (assuming that's the right change-over date) > I've added some extra information from the Microsoft open > specifications to the item which actually seems to make the use of > this header in POI date metadata extraction a bit suspect. It might > be better to drop the use of the message submission chunk for date extraction > moving forward. Once we have something to replace it with, that'd be good. That needs better fixed-sized property support though! > For moving HSMF forward, I'll have a think about what you said. My > knowledge of the current code base is pretty slack. Only the message > submission chunk really! Is the current code built upon HPSF or POIFS? > If so, I might start having a play with the Microsoft specs... POIFS. The property decoding is of MAPI properties, not OLE2 ones. Much of the decoding is there, the missing steps are around matching a property in the property chunk up to a poifs chunk with the value in, and then how to tie it all together at read time nicely Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] ____________________________________________________________ Electronic mail messages entering and leaving Arup business systems are scanned for acceptability of content and viruses --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
