Re: disk full

If you build the dependencies, let me know how that goes.  Everything is always harder to build on Windows than Linux.  I’ve always hated projects with a lot of big dependencies, but there’s no avoiding it, each one is essential. I still haven’t figured out how you managed to get a read exception rather than a write exception when your disk filled up. It’s unlikely but maybe possible that the incident could have messed up your block data file.  In that case, it might manifest as a similar exception again, or if your block count in the status bar stopped going up, that would also indicate a problem.  As of this moment it’s at 375 blocks. If there is a problem, it could easily be solved by deleting your block files, as follows: (exit Bitcoin and make sure it’s stopped) cd /d “%appdata%\bitcoin” (backup this directory first) del blk0001.dat del blkindex.dat It’ll then re-download the block chain.  Your transactions and generated blocks show as 0/unconfirmed until it’s done downloading. The crucial file to backup is wallet.dat.  If bitcoin is running then you have to backup the whole %appdata%\bitcoin directory including the database subdirectory, but even if it’s not running it certainly feels safer to always backup the whole directory. The database unfortunately names its files “log.0000000001”.  To the rest of the world, “log” means delete-at-will, but to database people it means delete-and-lose-everything-in-your-other-files.  I tried to put them out of harm’s way by putting them in the database subdirectory.  Later I’ll write code to flush the logs after every wallet change so wallet.dat will be standalone safe almost all the time. Satoshi Hi Satoshi - Sorry I have not been able to do more today, this looks like a busy week for me. I started 0.1.3 again under the MSVC debugger this time so if it crashes tonight I may be able to get some more information. I remember now that last night, my disk filled up. I had downloaded a bunch of the dependencies (boost, etc) with an eye towards trying to build it myself, and my disk was already pretty full. I’m pretty sure this is what caused 0.1.3 to crash. I’ve attached the debug.log, which also includes some other runs. The error is about 1/3 of the way down and says, EXCEPTION: NSt8ios_base7failureE CAutoFile::read : end of file Normally this should be a rare occurrence with the large disk sizes people have today. Hal

I hate duplicating code, but the compiler forces us. Copy the body of the function above it, like this:     void insert(iterator it, const_iterator first, const_iterator last)     {         if (it == vch.begin() + nReadPos && last - first <= nReadPos)         {             // special case for inserting at the front when there’s room             nReadPos -= (last - first);             memcpy(&vch[nReadPos], &first[0], last - first);         }         else             vch.insert(it, first, last);     } #if !defined(_MSC_VER) || _MSC_VER >= 1300     void insert(iterator it, const char* first, const char* last)     {         if (it == vch.begin() + nReadPos && last - first <= nReadPos)         {             // special case for inserting at the front when there’s room             nReadPos -= (last - first);             memcpy(&vch[nReadPos], &first[0], last - first);         }         else             vch.insert(it, first, last);     } #endif The modified version of serialize.h is attached. BTW, in my tests, VC8 produced an EXE that would only run on systems that had VC8 installed on them.  The error it gives is extremely vague.  I think they expect you to install a package during setup, but bitcoin doesn’t have a setup. My testing has been with MSVC 6.0 SP6 and GCC 3.4.5.  GCC is the release build.  There’s nothing wrong with the MSVC 6.0 build other than its optimization of the SHA routines for generating blocks is slow. Satoshi