Thanks for the feedback re: #57678 As you suspected (I think!), the check I used was back to front. Looking at the problem galvanised me to get POI/HSMF building under eclipse and the debugger, so I was able to step into the tests and see clearly how mad my original code was!
I've added test cases for the year transition, but I had to manually hack the data a little to generate the test cases. Is this acceptable? Modern emails just don't seem to include this property. At least the addition of the extra test data highlighted the problem you were alluding to... I'll have a closer look at PropertiesChunk.java and see what I can do now I've got Eclipse in a state I can work with... Thanks again for the info! Adrian -----Original Message----- From: Nick Burch [mailto:[email protected]] Sent: 22 March 2015 17:25 To: POI Developers List Subject: RE: Bugzilla item #57678 (Incorrect year parsing in message submission chunk) On Fri, 20 Mar 2015, Adrian Conlon wrote: > 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. If you have a copy of outlook to hand, I'd suggest trying to set the date on your machine to something a few decades ago, and send yourself a message. Check that, then push the date forward or backwards a few years, send again. Repeat until you have a file either side of the changeover! > 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 In Outlook, yes, and in theory, yes. Just not in HSMF (yet!) > 2) fixed length properties are entirely contained in this file Yes > 3) variable length and array properties are read from various > "__substg1.0_" prefixed files Variable length and array properties are stored in the __properties_version1.0 chunk, but their values are in the __substg1.0_ files. I think something about the property and/or what's stored in the fixed length area of the property value somehow tells you what __substg1.0_ to go to for the real value, but that's the missing step > 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? The __properties_version1.0 is mostly being decoded. The challenge is to work out how to link a variable property stored in there to a __substg1.0_ chunk with the real value I suspect that somewhere in the file format spec it'll explain that, I just haven't managed to find it since the spec was published (but I haven't had time to look very very hard...) 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]
