Fix issue with instances sharing config dir.

[efarrer]

Incorporate the --name into the state directory so that multiple instances will have unique state directories.

Fixes: #62

[antifuchs]

Hrm, I've been thinking about this change a bunch over the past days and I don't think it's quite right: Merging it will break all (my) installations where I pass a -stateDir that is already in the correct path... and all usages of the nixos config (which uses systemd's $STATE_DIRECTORY env variable, which is already per-service).

I think a slightly more compatible solution (which would still fulfill the ideas behind #62) would be to drop a file stating the tsnsrv instance's name into the state directory (using one of the plenty lockfile libraries, I think) - if another instance was run from that state directory with a different name, that state dir can not be used & this instance can exit with an error.

How does that sound?

[efarrer]

Hrm, I've been thinking about this change a bunch over the past days and I don't think it's quite right: Merging it will break all (my) installations where I pass a -stateDir that is already in the correct path... and all usages of the nixos config (which uses systemd's $STATE_DIRECTORY env variable, which is already per-service).

I think a slightly more compatible solution (which would still fulfill the ideas behind #62) would be to drop a file stating the tsnsrv instance's name into the state directory (using one of the plenty lockfile libraries, I think) - if another instance was run from that state directory with a different name, that state dir can not be used & this instance can exit with an error.

How does that sound?

This implementation checks the value of s.stateDir and only changes the behavior if the s.stateDir == "". So I don't think it will break backwards compatibility with installations that pass -stateDir or set the $STATE_DIRECTORY env variable. However, it does break backwards compatibility in the cases where a user has run a single instance on a machine without passing -stateDir or setting $STATE_DIRECTORY. I think I can use your suggestion to fix this backwards incompatibility and create a completely backwards compatible solution. Your comment has also made me realize that the business logic behind this is complex enough that it warrants some unit tests to document the behavior. I'll create a more robust solution and create a new pull request.

[efarrer]

Closing and will create a better solution.