init: log resolved datadir path when it differs #36373

pull LarryRuane wants to merge 1 commits into bitcoin:master from LarryRuane:2026-09-datadir-realpath changing 1 files +7 −1
  1. LarryRuane commented at 5:42 PM on September 28, 2026: contributor

    Because the data directory may be a symlink, also log the path it resolves to, so debug.log files show the actual location for that run.

    This patch would mostly help developers. I've been testing a potential performance PR across different data directories (for example, SSD versus HDD). After each run, I save the debug.log file. It would be nice if the debug.log file showed which data directory was used for that run.

    There are two ways to change which data directory to use: -datadir= on the command line, or by making the default path a symlink. If a script starts bitcoind (e.g., on an RPi with a whole infrastructure, like Umbrel or myNode), changing the startup command arguments may be inconvenient or not even possible. It's easy to change the default directory to be a symlink. But in that case, debug.log doesn't show the actual data directory location. This patch changes the existing startup log line to show the resolved data directory path (after following symlinks) if it differs from the nominal path.

    I don't think we need a separate test. I haven't tested on all platforms, but this patch uses primitives already used elsewhere, so it should work everywhere.

    Here's an example of the changed line during startup (omitting the timestamp prefix):

    - Using data directory /home/larry/.bitcoin
    + Using data directory /home/larry/.bitcoin (/sd/.bitcoin)
    
  2. DrahtBot commented at 5:42 PM on September 28, 2026: contributor

    <!--e57a25ab6845829454e8d69fc972939a-->

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    <!--006a51241073e994b41acfe9ec718e94-->

    External sites

    <!--021abf342d371248e50ceaed478a90ca-->

    Reviews

    See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

    <!--5faf32d7da4f0f540f40219e4f7537a3-->

  3. LarryRuane force-pushed on Oct 7, 2026
  4. in src/init/common.cpp:132 in 21e37651cc
     124 | @@ -124,7 +125,11 @@ bool StartLogging(const ArgsManager& args)
     125 |          LogInfo("Startup time: %s", FormatISO8601DateTime(GetTime()));
     126 |      }
     127 |      LogInfo("Default data directory %s", fs::PathToString(GetDefaultDataDir()));
     128 | -    LogInfo("Using data directory %s", fs::PathToString(gArgs.GetDataDirNet()));
     129 | +    const fs::path datadir{gArgs.GetDataDirNet()};
     130 | +    LogInfo("Using data directory %s", fs::PathToString(datadir));
     131 | +    std::error_code ec;
     132 | +    const fs::path real_datadir{fs::canonical(datadir, ec)};
     133 | +    LogInfo("Resolved data directory %s", fs::PathToString(ec ? datadir : real_datadir));
    


    l0rinc commented at 1:19 AM on October 8, 2026:

    The commit message says the resolved path is "always printed", but the PR title says "when it differs".

    Is this part of a broader effort to improve symlink support? If so, I wouldn't want to see two separate log lines for the exact same folder in 99% of cases.


    LarryRuane commented at 2:13 PM on October 8, 2026:

    Thanks for taking a look. The first version of this PR printed the resolved path at the end of the same line that exists today:

    - Using data directory /home/larry/.bitcoin
    + Using data directory /home/larry/.bitcoin (/sd/.bitcoin)
    

    And it added that path only if it was different from the "Using" path. But after more thought, it seems better to log a new line ("Resolved") and leave the existing log line unchanged (in case scripts exist somewhere that expect the current format). I also thought it would be better to always log this new Resolved line so future scripts can look for it without needing logic to fall back to "Using" if "Resolved" doesn't exist. So I force-pushed those changes. But I forgot to update the title; fixed now.

    Sounds like you would like the Resolved line to only print if it's different; I can make that change, I don't feel strongly either way.

    No, I'm not thinking this is part of a broader effort to improve symlink support. AFAIK symlinks are already fully supported. It's just a self-contained PR that would have helped me personally, since I saved a bunch of debug.log files and later wasn't sure whether each corresponded to an SSD or an HDD data directory run (because I had changed a symlink). Plus, it seems generally useful to know where the actual data directory is.

    I can make the logging of that Resolved line conditional so it doesn't print the same path as the Using line, maybe I'll wait for a few more opinions.


    sedited commented at 8:10 PM on November 6, 2026:

    in case scripts exist somewhere that expect the current format

    I don't think we should operate under this assumption. We should have the freedom to change log lines. Your suggestion of printing the resolved location on the same line seems fine to me.


    LarryRuane commented at 4:13 PM on November 9, 2026:

    Thanks, reverted (force-pushed) to the earlier version that modifies the existing line, instead of printing a separate line.

  5. LarryRuane renamed this:
    init: log resolved datadir path when it differs
    init: log resolved datadir path
    on Oct 8, 2026
  6. init: log resolved datadir path when it differs
    If the data directory (or a parent) is a symlink, also log the path it
    resolves to.
    8ef14db305
  7. LarryRuane force-pushed on Nov 9, 2026
  8. LarryRuane renamed this:
    init: log resolved datadir path
    init: log resolved datadir path when it differs
    on Nov 9, 2026

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-11-13 23:51 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me