Good morning! Here is the latest version of my PR_ENTRYID patch:
This fixes a number of problems with the previous patch:
- We no longer support calculating PR_ENTRYID for attachments.
- We raise an error if the user tries to calculate PR_ENTRYID for a submessage.
- All the support code now lives in the PST layer, as requested.
- The generated PR_ENTRYID values have now been checked against MFCMAPI, as requested. And this was a
very good idea—my earlier code was outputting the last 4 bytes in big-endian order. This bug has now been fixed. Thank you for helping me get some real-world test data!
However, some of the issues raised above have not yet been addressed:
- I haven't added support for calculating the PST's PR_ENTRYID.
- I haven't added support for opening a message or folder by PR_ENTRYID.
- I haven't added any code to detect OST files and either (a) raise an error or (b) calculate a correct PR_ENTRYID.
Issues (1) and (2) are highly desirable features, but they're not required by our application. And since we wouldn't use them, I'd be coding somewhat blindly and I would risk writing code that fails in the real world. Would it be OK to leave the implementation
of (1) and (2) to somebody who'll be using them with real data?
Issue (3) definitely needs to be addressed. Is there an easy way to tell a PST from an OST without relying on the file extension? Is there an easy way to calculate correct OST PR_ENTRYID values? And would it be possible to add a sample OST file to the 'pstsdk/test'
directory? (I don't think we have any OST files that we can redistribute.)
As always, thank you for reviewing patches, and for all your advice!