This project is read-only.

Getting access to header information

Jun 10, 2010 at 5:27 PM

I'd like to find out some information about the store I've opened ... Whether it's an OST or PST, if it's ANSI or UNICODE, etc.  I know it's all in the m_header member in the db level, but can we have a public way to get access to it?

Jun 10, 2010 at 5:38 PM

Well, the entire point of the db_context class and implementors is to abstract away and hide this information - so I'm hesitant to put this type of information as part of the db_context interface (which is already threatening to grow to be too monolithic). Exposing m_header directly isn't possible, because the m_header type is a template type dependent on if the file is unicode or ANSI (where as db_context has no concept of unicode versus ansi).

Why not drop down to the disk layer and read the disk header structures from the file yourself?

Jun 10, 2010 at 5:40 PM

I suppose I could do that ... I wasn't thinking of exposing m_header directly, merely exposing a few get_xx() props to find out some basic information about the file I've just opened.

However, I think just accessing things from the disk level would give me more control and flexibility.


Jun 10, 2010 at 6:16 PM

Which ones specifically are you interested in? Just OST vs. PST, ANSI vs. Unicode? My only concern is that the db_context interface is already huge. 

Jun 10, 2010 at 6:26 PM

I don't think there's really anything interesting to know about the header other than wVerClient, wVer and bCryptMethod.  Strictly for informational/metadata/categorization purposes in my line of work.

Jun 10, 2010 at 6:29 PM

I've already gone and collected that stuff at the disk level with a few lines of code:

template<typename T>
class database_check : public database_impl<T>
  database_check(const wchar_t *filename) : database_impl<T>(filename)

  bool is_ost()
    return (m_header.wVerClient == pstsdk::disk::database_ost);

  pstsdk::byte crypt_method()
    return m_header.bCryptMethod;

Then I just use some try/catch blocks, and instantiate the class either with <ulong> or <ulonglong>, catching the invalid_format exception, which tells me ANSI or UNICODE ... then the methods themselves tell me the rest.