Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid startup failure when appDataDir is a symbolic link #4002
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 #3998.
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 #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.
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.