Ok, it was upgrade time – a batch of 320kbps MP3’s wouldn’t batch-import reliably (later ones came in as flatline, even though they would import properly as a single file import) – and I wasn’t on the current release.
Grabbed the 2.1.2 dmg, opened it, dragged, chose Merge (which might have been a bad idea; if it matters, the background image in the DMG ought to be changed to say so), and then I went into a loop:
First time: Launches, no system errors about Gatekeeper as in my earlier posting, dies with no message.
Second time: Launches, gives a dialog box about the temp directory being locked (without saying where it thinks that is, about which I will RFE later), dies with, otherwise, no message.
If I manually remove the lock file in the tempdir, we go back to First time.
I redid the drag-install, wanting to choose replace, but I didn’t get the choice. Same results.
So I renamed the folder under Applications to 2.1.0-Audacity and did what I assumed was a clean drag-install from the DMG. Still the same results.
ISTR there’s somewhere I can find out why it thinks it’s dying, but I cannot recall where that is. Can anyone tip me off?
The latter, yes, which I would contend ought to tell the user where Audacity was looking for the proof it found that Audacity was already running (which it often is not; the message might better be
Audacity has discovered its own lock file on startup in
which means that either another copy is running, or the program previously crashed without cleaning up after itself.
Also, it appears to me that if you override the lockfile, it is not removed when you clean-exit,
and hence is still there next time. That would be a design decision rather than a bug, but I myself would pick “it should be removed”.
As Leland said https://forum.audacityteam.org/t/cant-open-audacity-on-my-mac/37597/14 there are probably bugs in wxWidgets which prevents it removing the old lock file as it should. But you’re the first person I’ve seen so far who has had a problem with the lock file in 2.1.2. It could be that the deletion of the lock file failed because Audacity was not starting up properly, which seemed to be some separate problem.
Rather than us state the lock file location, which could encourage people to delete the file so as to run multiple Audacity instances at once, it would probably be better to make a dialogue which asked if the user wanted to restart Audacity, whereupon Audacity could try to force delete any lock file it found.
How are you choosing to override the lock file? In the dialogue “Audacity was not able to lock the temporary files directory”?