Wallet salvage searches for `wallet.dat` in the current directory rather than .bitcoin #6582

If you try to start bitcoind with a corrupted wallet, it will attempt to run CWalletDB::Recover, which moves wallet.dat to some other name, reads all the records, and writes them to a fresh wallet.dat.

However, when moving wallet.dat, it searches the current directory rather than .bitcoin, so if you start bitcoind from anywhere else, it'll fail. To see this, run

echo "I'm not a real wallet!" > ~/.bitcoin/wallet.dat  ## MOVE YOUR REAL WALLET OUT OF THE WAY
bitcoind

The output on stdout is simply "Error:" with no additional information. In debug.log you will see something like

2015-08-23 16:13:17 CDBEnv::Open: LogDir=/home/apoelstra/.bitcoin/database ErrorFile=/home/apoelstra/.bitcoin/db.log
2015-08-23 16:13:17 Failed to rename wallet.dat to wallet.1440346397.bak (err -1)
2015-08-23 16:13:17 errno 2: No such file or directory

(The errno line won't appear; I added that while investigating the bug.)

On the other hand, if you run bitcoind from ~/.bitcoin itself, it will rename the wallet successfully (and instead fail trying to read records from "I'm not a wallet!" :)).

Confirmed (but maybe also a different error than @apoelstra, but probably same root). Just tested with a corrupted regtest wallet and got:

Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open: LogDir=<snip>/regtest/database ErrorFile=/<snip>/db.log
Failed to rename wallet.dat to wallet.1440416498.bak
Error: 
Error: 
Shutdown: In progress...

From the BDB docs:

The DB->rename() method may not be called after calling the DB->open() method on any DB handle. If the DB->open() method has already been called on a DB handle, close the existing handle and create a new one before calling DB->rename().

If I follow the code correctly, we do a Open before we try the DB->rename().

Will try to write a fix.

Sorry. Reported wrong. Works for me.

If the wallet.dat if fully corrupted like @apoelstra "echo" example, a rename is not possible (results error 22 = Invalid argument). If a salvaging is possible, the rename does work independent from current working directory. If the rename locations are faulty (on some os), it is very likely a upstream issue because our code calls:

int result = dbenv.dbenv->dbrename(NULL, filename.c_str(), NULL,
                                       newFilename.c_str(), DB_AUTO_COMMIT);

@jonasschnelli it's possible I misunderstood the problem because I replaced dbrename with a cstdio rename to get the errno output. Then I assumed rename's "file not found" problem was the same one that dbrename was giving me (which was actually "database too corrupted to be opened").

Does that explain both our observations?

@apoelstra: my tests did show me that dbrename will response with invalid argument if the database is "too corrupted". File not found is also possible, but only happened in my test if i have used a non-existing filename. The filename is relative because dbrename assume that we already have initialized a db context (with path/file, etc.).

Looks like the user changed code which may have resulted in this problem, the issue is inactive, so closing.