Resolve path to allow for Bitcoin directory to be a symlink #2590

mcdee commented at 11:11 AM on April 29, 2013: none

At current if your .bitcoin directory is a symlink (which is becoming more likely as the size of the blockchain increases) then bitcoind will fail to start. This is because fs::create_directory() fails if it is called on a symlink.

This patch resolves the symlink and stores it in the path cache prior to creating the directory, ensuring that operations are always carried out against the correct location and work as expected.

SIDE-EFFECT: Because the fully resolved path is stored in the path cache any error messages that are returned which include the path now show the canonical (i.e. resolved) path. I think that this makes more sense for users and developers, however if this is not desired it would be possible (albeit somewhat more expensive) to only use the canonical path for the create_directory() call and leave the path unresolved elsewhere.

jonasschnelli commented at 12:43 PM on April 29, 2013: contributor

MacOSX: after pulling i get a SIGABRT somewhere in boost::filesystem::detail::canonical. Question: when i create a "ln -s" the current stable client works perfect without this fix (testes MacOSX). Do you say, till now it was not possible to symlink "ln -s" the .bitcoin directory on linux?

sipa commented at 12:45 PM on April 29, 2013: member

My .bitcoin directory is symlinked on Linux.

mcdee commented at 1:06 PM on April 29, 2013: none

It looks like the specific situation which the patches address is when the link points to an NTFS filesystem. When the link points to an EXT3 filesystem it works without the patch. @jonasschnelli which version of boost are you using?

jonasschnelli commented at 1:16 PM on April 29, 2013: contributor

@mcdee boost @1.53.0, Revision 1 (devel)

Diapolo commented at 4:27 PM on April 29, 2013: none

Can you squash your 2 commits into one please.

Resolve path to allow for Bitcoin directory to be a symlink

Conditional use of fs::canonical only if using filesystem v3

b3d9e2f682

gavinandresen commented at 8:37 PM on April 29, 2013: contributor

NACK on adding more code just to support a weird configuration like a symlink pointing to a NTFS filesystem.

mcdee commented at 9:49 AM on May 3, 2013: none

Well the configuration in this case is a dual-boot desktop for both Windows and Linux, attempting to share the blockchain between the two installs. Not sure if it counts as "weird" but I'm happy to accept that this is a non-supported setup.

Merge remote-tracking branch 'upstream/master' into symlinks a5d2f062a5

laanwj commented at 1:52 PM on May 5, 2013: member

I don't think you have a weird configuration, and don't see any harm in supporting it. However, I don't think this is the right solution to your problem.

Looking at the root of the issue: why is fs::create_directory called when the symlink already exists?

mcdee commented at 3:20 PM on May 5, 2013: none

fs::create_directory is designed to return without error if the directory already exists. So it works fine in the situations where a directory already exists, or a directory doesn't already exist. However when there is a symlink in place of the directory which points to the NTFS partition it throws an error. Resolving the path prior to the call to fs::create_directory avoids the issue as it reverts to one of the first two mentioned cases.

BitcoinPullTester commented at 5:36 PM on May 10, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a5d2f062a5757cc890bbd26b08d77f1581b8b7e7 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

rebroad commented at 4:56 AM on May 12, 2013: contributor

@gavinandresen Why do you consider this a "weird" configuration? I suspect it's a fairly common one. Certainly a symlink to a NTFS partition should be supported, IMHO. Why shouldn't it be?

sipa commented at 8:49 AM on May 12, 2013: member

In any case, this patch looks pretty safe to me.

Diapolo commented at 11:32 AM on May 13, 2013: none

@sipa I also think there is no real maintain-cost here.

What I would like is a little comment, what this does in the code.

jonasschnelli commented at 1:00 PM on May 13, 2013: contributor

just for the records: fs::canonical(path); does crash with SIGABRT on my mac. So we might wrap the new code with some #ifdefs for linux.

jgarzik commented at 4:29 PM on May 30, 2013: contributor

@jonasschnelli Ouch. Can you confirm this happens on HEAD + this patch?

In general, "meh" Symlinks currently work. Some people might notice that their $datadir as applied differs from the one specified, e.g. /home/real/path/to/my/data rather than /my/data.

jonasschnelli commented at 7:08 PM on May 30, 2013: contributor

ACK

checked out HEAD + this commit
having boost [@1](/bitcoin-bitcoin/contributor/1/).53.0 (devel) (installed trough port)
running standard 10.8.3 run's smooth

But i didn't test against a symlink pointing to a NTFS drive (NTFS connection are very rare on mac).

goldbit89 commented at 5:45 AM on May 31, 2013: none

could this be the reason im getting error : error opening file for writing: c:\program files (x86)\bitcoin\bitcoin-qt.exe

in issues 2707 and 2712.

i found a lock i thought was holding the bitcoin folder and sub folders along with files but i do not know how to proceed from here and pondering if i should uninstall 8.1 and also wondering if i uninstall if i will lose my database and wallet?

Thanks.

Diapolo commented at 10:03 AM on July 11, 2013: none

I'm still supporting that change, as the configuration seems more common, than we thought.

in src/util.cpp:None in a5d2f062a5

1070 | @@ -1071,6 +1071,9 @@ void PrintExceptionContinue(std::exception* pex, const char* pszThread)
1071 |      if (fNetSpecific && GetBoolArg("-testnet", false))
1072 |          path /= "testnet3";
1073 |  
1074 | +#if BOOST_FILESYSTEM_VERSION == 3
1075 | +    path = fs::canonical(path);
1076 | +#endif
1077 |      fs::create_directory(path);

luke-jr commented at 8:58 PM on July 16, 2013:

We're using create_directories now. Does it have the same issue?

gavinandresen commented at 1:43 AM on October 21, 2013: contributor

Closing due to inactivity, and because we're using create_directories now this may no longer be an issue.

If it is still an issue, feel free to open a new pull request.

gavinandresen closed this on Oct 21, 2013

laxris commented at 10:19 PM on November 2, 2013: none

Since I moved the Bitcoin folder from %appdata%\Roaming and junction-linked it, I receive a MS Visual C++ Runtime Library error stating:

"This application has requested the Runtime to temrinate it in an unusual way. Please contact the application's support team for more information."

Can other junction users confirm this issue?

ughman commented at 3:58 AM on December 13, 2013: none

I can confirm the issue running the win32 binary release for v0.8.6 under Windows XP with a junction link from %APPDATA%\Bitcoin to K:\bitcoin-0.8.6-win32\data with the same error message.

laanwj commented at 4:10 AM on December 13, 2013: member

@ughman Is this the case with master too? A lot changed since. 0.8.6 was only a maintenance release.

ughman commented at 4:47 AM on December 13, 2013: none

@laanwj I do not have an environment capable of building master at the moment, so I cannot test that. Sorry.

DrahtBot locked this on Sep 8, 2021