pull down to refresh

Yup. They are all there.

The firs link is direct download to debug.log file.

Good news, looks like the behavior of debug logs back then was to append new sessions, not overwrite them. given this, looks like Hal started up his bitcoin client three times, synced a bit in the first, and failed to do so in the 2nd and third attempts. cool.

#define printf OutputDebugStringF

Then OutputDebugStringF() opens the log like this:

FILE* fileout = fopen("debug.log", "a");

That "a" mode is append mode, not overwrite mode. The function writes with vfprintf() and closes the file each time. So, under the same binary, same working directory, and same debug.log, a second startup should add to the bottom of the existing log, not erase the first run.

There is one subtle thing: on startup the client prints a large block of blank lines and then:

Bitcoin CMyApp::OnInit()

So a second startup could visually look like a “fresh” section of log because it begins with lots of blank space. But the older log content should still be above it unless the file was manually deleted/truncated, the program was launched from a different working directory, or Hal was using a different/debug build setup.

The nearby comment about “deleting log.*” is probably not about debug.log. It appears in the startup code as a database-protection note, and the DB code separately configures Berkeley DB logs under a database directory and uses dbenv.log_archive(... DB_ARCH_REMOVE) during shutdown cleanup.

So my conclusion:

The “second startup wiped the first debug.log” theory is not supported by this codebase.
reply

Yup.

And how luckly is that this was an append mode?
If not for this We could not be so sure of these things?

I mean we would still get last session, but this makes it even better.

reply

really great stuff, thank you for making bitcoin history.

reply

Thank, but i did not make it(not this time :p)I just wrote about it

reply

so humble, stack sats.

reply

Humility is the enemy of greatness.

reply