Lockfiles not removed in several scenarios #31
Description
Transferred from https://github.com/original-male/non/issues/270
If you load a session a .lock file gets created. If you close with /nsm/server/close the lockfile gets deleted. It also works with abort and with creating a new session.
However, if you choose to open a new session with /nsm/server/open the current sessions lockfile remains. Even when the new sessions gets closed, the first lockfile remains.
The lockfile also remains if you duplicate the current session, which closes the current one.
I believe in the case of duplication and switching this is a bug and the lockfile should be deleted.
If you create a new session, which NSM automatically opens, no lockfile gets created.
Legacy-GUI: even with a lockfile present, the session will still open. There are no relevant tests for the lockfile.
It is very rare that I see the popup-dialog that a session is already locked. In fact I can't remember I have ever seen it except someone opened two non-session-manager GUIs by accident. Otherwise these are false-positives: If the files are write-protected or ( nsmd.cpp load_session_file() ) if session's folder doesn't exists, it answers "/error ERR_SESSION_LOCKED session is locked by another process.".
See also this PR where I discuss if lockfiles should be removed completely
#30
It is also possible to move the lockfiles out of the session dir and into a temporary directory that will get cleaned up by the OS. Then a real computer crash (no electricity) will not lock a session over a reboot.
A fixed and known outside location could also be used for server lookup. The lockfiles could contain NSM Urls so that external programs, scripts and launchers can look up if a session is currently running and under which OSC-URL.