Closed dreid closed 10 years ago
Great, thanks for the report! Yes, making sure the path is a normalized before subjecting Tor to it is a great idea.
Also, yes the launching code is supposed to not delete the directory if it was user-specified...Hopefully this is just an artifact of the two-segment relative paths "not working", but I should also test that.
I think the "foo" directory getting destroyed was from Tor; with the relative paths, it got itself into a bad state and exited. This wasn't getting logged (it is now), and txtorcon also creates the directory if you specify a non-existent one using hiddenServiceDir.
Please re-open if you find it doesn't work for you. thanks!
I've found a few cases where
hiddenServiceDir
being passed through to the underlying tor configuration causes a violent crash with very few clues as to what the problem is.An example with a
~/
path:I assume this is because the value is passed directly through to the tor configuration file and Tor doesn't know how to expand these paths.
Other things that fail are relative paths with more than one segment:
foo/bar
.Relative paths with one segment fail in a slightly different way:
This causes a directory
foo
to be created under theDataDirectory
, which is a valid hidden service directory unfortunately txtorcon no longer knows about it and can't display the hostname in the output. Also it now gets destroyed when the reactor is shut down, which seems to defeat the purpose of specifying your own hiddenServiceDir.It'd be nice if txtorcon could resolve relative and ~ paths.