<!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

When naming a configuration file using a relative path using the -conf command line parameter, the configuration parser will present an error if the datadir option is listed in the named configuration file. The configuration parser will expect the named config file in both the default datadir and the named datadir.

For example. Given the config file named usb.conf with the contents:

# Bitcoin Config file: %APPDATA%\Bitcoin\usb.conf
datadir=D:\Bitcoin

And calling bitcoin with the following "%PROGRAMFILES%\Bitcoin\Bitcoin-qt.exe" -conf=usb.conf the config parser will present an error if D:\Bitcoin\usb.conf does not exist. Clearly it has found and parsed %APPDATA%\Bitcoin\usb.conf but yet it still needs to parse D:\Bitcoin\usb.conf

Expected behavior

Command line arguments should trump config file arguments. So since -datadir is not specified on the command line, the location for the named config file should correctly resolve to %APPDATA%\Bitcoin\usb.conf without further dependencies on D:\Bitcoin\usb.conf. Once the initial path location is resolved, it should not be reevaluated. This is understandably a "special case". Normally relative paths are resolved from datadir, but the -conf parameter is already special in the sense that is not supported in the config file parsing, so should not be influenced by what is parsed from the config file.

Actual behavior

The config parser throws an error if the config file does not exist both in the default datadir and the named datadir

Note, as a workaround, providing the full path to the config file mutes the error. This is only related to how relative paths are interpreted.

To reproduce

Completely reproducible

System information

• Windows 10.0.18363 Build 18363
• Precompiled 0.20.1 Windows x64 binaries landed from installer downloaded from bitcoin.org
• Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz, 3001 Mhz, 4 Core(s), 4 Logical Processor(s)
• Disk0: WDC WD10EZEX
• Disk1: Generic USB mounted SSD

<details> <summary>Expand for debug.log</summary> <pre> 2020-09-22T03:00:12Z Bitcoin Core version v0.20.1 (release build) 2020-09-22T03:00:12Z Qt 5.9.8 (static), plugin=windows (static) 2020-09-22T03:00:12Z System: Windows 10 (10.0), x86_64-little_endian-llp64 2020-09-22T03:00:12Z Screen: \\.\DISPLAY1 1920x1080, pixel ratio=1.0 2020-09-22T03:00:12Z Assuming ancestors of block 000000000000056c49030c174179b52a928c870e6e8a822c75973b7970cfbd01 have valid signatures. 2020-09-22T03:00:12Z Setting nMinimumChainWork=0000000000000000000000000000000000000000000001495c1d5a01e2af8a23 2020-09-22T03:00:12Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation 2020-09-22T03:00:12Z Using RdSeed as additional entropy source 2020-09-22T03:00:12Z Using RdRand as an additional entropy source 2020-09-22T03:00:12Z GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely..." 2020-09-22T03:00:12Z Default data directory C:\Users\{redacted}\AppData\Roaming\Bitcoin 2020-09-22T03:00:12Z Using data directory d:\Bitcoin\testnet3 2020-09-22T03:00:12Z Warning: The specified config file d:\Bitcoin\usb.conf does not exist 2020-09-22T03:00:14Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements 2020-09-22T03:00:14Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements 2020-09-22T03:00:14Z Script verification uses 3 additional threads 2020-09-22T03:00:14Z scheduler thread start 2020-09-22T03:00:14Z Using wallet directory d:\Bitcoin\testnet3\wallets 2020-09-22T03:00:14Z init message: Verifying wallet(s)... 2020-09-22T03:00:14Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2020-09-22T03:00:14Z Using wallet d:\Bitcoin\testnet3\wallets 2020-09-22T03:00:14Z BerkeleyEnvironment::Open: LogDir=d:\Bitcoin\testnet3\wallets\database ErrorFile=d:\Bitcoin\testnet3\wallets\db.log 2020-09-22T03:00:14Z init message: Loading banlist... 2020-09-22T03:00:14Z Using /16 prefix for IP bucketing 2020-09-22T03:00:14Z Cache configuration: 2020-09-22T03:00:14Z * Using 2.0 MiB for block index database 2020-09-22T03:00:14Z * Using 8.0 MiB for chain state database 2020-09-22T03:00:14Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space) 2020-09-22T03:00:14Z init message: Loading block index... 2020-09-22T03:00:14Z Opening LevelDB in d:\Bitcoin\testnet3\blocks\index </pre> </details>

Thanks for the clear bug report! Agree this behavior is not good. I tend to think a simpler fix would be to just disallow relative -conf paths entirely, making specifying any relative -conf path an error, instead of interpreting relative -conf paths differently depending on the source of the -conf value (command line vs config file vs settings.json).

Another benefit of making specifying a relative -conf paths an error instead of changing the interpretation would be that that if someone is relying on current behavior and upgrades they can encounter an explicit error instead of a subtly broken configuration.

Maybe this is too extreme though? @brianddk maybe you had a use-case for specifying a relative path instead of an absolute path?

A compromise option instead of forbidding relative -conf paths outright, or interpretting relative -conf paths differently depending on where they are specified might be to only forbid relative -conf paths when a -datadir value is specified.

@ryanofsky I think relative paths within the config file should probably stay, but agree that relative paths in a named -conf parameter could be nixed. I would think the more common answer is that relative paths in command-line parameters would be assumed relative to $PWD, which seems to be what most of the unix tool do. This would be a move more to "convention" as opposed to fixing some weird use case.

Relative paths within a config file have no real "convention" to hold to, so I see no need to change that behavior, assuming the two behaviors can be divorced from each other.

I tried to reproduce on macOS on master @ 20bd591345, there is still a warning (examples below). This issue is solved by #27303!

Absolute -conf path

conf file (/private/tmp/cdata/bitcoin.conf):

datadir=/tmp/tmp2

command:

bitcoind -conf=/private/tmp/cdata/bitcoin.conf

output:

...
2023-03-27T14:40:02Z Default data directory /Users/matthewzipkin/Library/Application Support/Bitcoin
2023-03-27T14:40:02Z Using data directory /tmp/tmp2
2023-03-27T14:40:02Z Config file: /private/tmp/cdata/bitcoin.conf
2023-03-27T14:40:02Z Config file arg: datadir="/tmp/tmp2"
2023-03-27T14:40:02Z Command-line arg: conf="/private/tmp/cdata/bitcoin.conf"
...

behavior: bitcoind starts with no errors, uses /tmp/tmp2 as datadir and blocksdir.

Relative -conf path

conf file (/Users/matthewzipkin/Library/Application\ Support/Bitcoin/relative/bitcoin.conf):

datadir=/tmp/tmp2

command:

bitcoind -conf=relative/bitcoin.conf

output:

...
2023-03-27T14:46:11Z Default data directory /Users/matthewzipkin/Library/Application Support/Bitcoin
2023-03-27T14:46:11Z Using data directory /tmp/tmp2
2023-03-27T14:46:11Z Warning: The specified config file /tmp/tmp2/relative/bitcoin.conf does not exist
Warning: The specified config file /tmp/tmp2/relative/bitcoin.conf does not exist
2023-03-27T14:46:11Z Config file arg: datadir="/tmp/tmp2"
2023-03-27T14:46:11Z Command-line arg: conf="relative/bitcoin.conf"
...

behavior: bitcoind starts with no errors, uses /tmp/tmp2 as datadir and blocksdir.

This issue is solved by #27303

Good find, agree it solves originally reported issue.

It might still be a little confusing that relative -conf paths would be allowed on the command line, and wouldn't be interpreted relative to the current working directory or to the final datadir location, but relative to the default datadir location. But arguably there are uses cases for this behavior (like putting multiple 1.conf, 2.conf files in the default datadir location, and having them specify different options and different final datadir= paths internally, and so you can conveniently pass -conf=1.conf or -conf=2.conf options on the command line that will work regardless of the current working directory).

Will this issue be closed by #27302 ?

Will this issue be closed by #27302 ?

Yes specifically it is fixed by the third commit 0319de5cbedd1a8f8766cfec61151c58b3fb27ef from #27302. That commit changes the ArgsManager::GetConfigFilePath definition so the "The specified config file %s does not exist" warning is no longer triggered:

https://github.com/bitcoin/bitcoin/blob/91ccb62faab21b2b52b089cc04f3a5c1bf6989cc/src/init/common.cpp#L125-L130

Closed by https://github.com/bitcoin/bitcoin/pull/27302