Can launch Bisq only after system restart on Windows

[freimair]

This issue might address #1023, #1161, possibly #791, #1299 and more recent reports even from @ManfredKarrer himself. The issue is meant as a progress tracker.

Issue

Bisq gets started. Bisq runs. Bisq gets closed and exists gracefully (?). Nothing wrong yet.
Now, Bisq gets started again, and it refuses to start with:

ERROR i.b.n.p.n.TorNetworkNode: Tor node creation failed: java.lang.RuntimeException: Could not delete file C:\Users\Name\AppData\Roaming\Bisq\btc_mainnet\tor\lock 

Fixes

restart your machine

Affected platforms

Windows

Findings so far

The Tor process creates a file named lock in the Tor working directory. It has size 0 (as expected for a lock file), gets created as soon as the tor-binary is executed, and is in turn owned by the Tor process. However, at least on my Arch linux machine, the file does not get deleted after Tor shutdown and is only overwritten on a fresh start of Tor.

Ah yes, and this behaviour does apply to bisq, the netlayer tests and the TorBrowser-bundle as well. It seems like the issue might be located in Tor itself.

EDIT: I just found the piece of code in netlayer, which is trying to delete the file and fails doing it. It is preceeded by

        // It can take a little bit for the Tor OP to detect the connection is dead and kill itself
        Thread.sleep(1000)

Timing issue?

Help needed

I cannot reproduce the issue right now. However, if anyone stumbles upon the issue, please check if a Tor process is still running on your machine. If so, try force-killing the process and start Bisq again.

[ManfredKarrer]

I saw it when I installed Bisq on windows VM with AV software installed. The AV took ages at installation time to verify Bisq and either I killed it then (dont remember exactly) or the AV terminated Bisq. Then after trying to start it did not work anymore bc of the lock file. After a OS restart all was fine again. I think on Windows the new process did not had the permission to delete the old lock created by an prev. process.

[freimair]

hm. Netlayer tries to delete the file itself when the first startup attempt is not successfull. So I do not believe that the new process has no permission to delete an old lock - in the end, it is always Windows and its permission system.

I would suggest, when the issue shows itself again, that we find the process that locks the file (with something like that). If it says it is AV, then we are set. If it says Tor, I can tweak the shutdown procedure in Netlayer. If it says something different, we can go on.

[ripcurlx]

We changed some tor startup handling a long time ago that fixed certain Windows startup issues. I think this issue can be closed now.