Here's a good question for you about the C++ I/O.
If I can't get this solved, I'm going to have to scrap the entire I/O and go for MFC/pure C.
Consider this:
Code:
CRegistry::ERROR CRegistry::LoadHives(CRegistry::CHive& rHive)
{
m_Key.sIndex.seekg(0); // Make sure we're at the beginning of the file
FAIL_FILEOP(m_Key.sIndex >> rHive.nFreeId, m_Key.sIndex);
FAIL_FILEOP(m_Key.sIndex >> rHive.nLastOffset, m_Key.sIndex);
return CRegistry::ERROR_SUCCESS;
}
CRegistry::ERROR CRegistry::SaveHives(CRegistry::CHive& rHive)
{
FAIL_FILEOP(m_Key.sIndex << rHive.nFreeId, m_Key.sIndex);
FAIL_FILEOP(m_Key.sIndex << rHive.nLastOffset, m_Key.sIndex);
m_Key.sIndex.flush(); // Flush buffer to make sure it can be read later
return CRegistry::ERROR_SUCCESS;
}
We don't need to know many details besides that rHive.nFreeId && rHive.nLastOffset == UINT64 && is equal to 0.
So when I print these to the files, I find the following in the files:
"00" - A STRING (plus only 2 bytes) when I'm actually writing a UINT64, which is 8 bytes!
And of course it affects the reading. I seek back to the beginning and try to read into the same variables later, and what do you know, the first read sets the EOF flag and the second FAILS because it reads after the end of the file!
It converts everything to STRINGS, truncates it and writes to the file and FAILS to read it properly next time.
Maybe I just don't know how to use it, but this looks just like a bother to me.