Avoid startup failure when appDataDir is a symbolic link #4002
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, Config#mkdir and #mkAppDir threw ConfigException if any underlying IOException was thrown from Files#createDirectory or Files#createDirectories respectively. This resulted in only a simple error message being reported at the command line and the details of the underlying exception's stack trace were lost. This change wraps and rethrows the underlying IOException as an UncheckedIOException such that it gets caught by the catch(Throwable) clause in BisqExecutable, which does print a stacktrace to stderr. This is the way it always should have worked; throwing ConfigException in these cases was an oversight in the original implementation. This change also removes the ConfigException constructor that allows for passing a nested exception to be wrapped as there is actually no use case for this now that these two anomalies have been corrected. This change was made in the process of attempting to reproduce bisq-network#3998.
cbeams
force-pushed
the
debug-appdir-creation
branch
from
f5ca539 to
de537f0
Compare
ripcurlx
added
the
is:priority
|
Heads up, I am about to push some additional commits to this PR branch that properly fix #3998. I'll update the title and description of the PR accordingly after doing so. Please don't merge in the meantime. |
This is a pure refactoring that renames and inlines variables to tighten up and make more consistent the implementation of these two methods. It is done in preparation for a subsequent substantive change that fixes a bug.
This change fixes bisq-network#3998 by avoiding the attempt to create a user's appDataDir if it already exists. Normally this attempt is not a problem, as Files#createDirectories does nothing if the target is a directory that already exists, but in the case that the target is a symbolic link, Files#createDirectories throws a FileAlreadyExistsException. This change prevents the call to Files#createDirectories if the target already exists, and if in fact the target is a symbolic link pointing to an existing directory, this is not a problem and everything proceeds as per usual. This mimics the behavior in Bisq v1.2.5 and prior, where File#mkdirs was used instead of Files#createDirectories. File#mkdirs does not throw an exception when the target directory is a symlink, it just returns false.
cbeams
changed the title
|
I've updated the title and description of this PR to reflect the actual fix. I've now gotten confirmation from both affected users that they were using symbolic links in their appDataDir paths, so we should be good to go to merge this, i.e. we should feel confident that these changes actually fix the bug. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #3998 as explained in the commit comment for cbe6f19.