There seems to be an issue with the InterprocessLock on OSX (in the juce master branch, but I didn’t find any thread that suggest this is fixed in modules).
Isn’t the idea that the /var/tmp/juceAppLock_* files are supposed to be deleted when the application shuts down? It seems that (on OSX 10.6.8 ) those files never get deleted. This doesn’t result in any problems when you are only using a single user account. Even those applications that allow only one instance (by overriding JUCEApplication::moreThanOneInstanceAllowed) work fine.
However, when you try to start a standalone juce application that has the single instance limitation enabled with different user account, it will exit immediately and silently for the second user, since (s)he does not have write permissions to the lock file.
Is this a known issue, already fixed in the modules branch? Or is there anything we could and have to do to fix this in our application code?
I think on the modules branch, that file will now go into a user’s home folder, so the problem shouldn’t occur…
Thanks that good to know. I hope that change can be easily be back-ported, we’re close to a maintenance release and I’d rather not to the switch to the modules branch right now.
Can you point me to the commit(s) where you changed this? I couldn’t locate it with a quick search in the git history.
I don’t have time to dig through the commits, but if you have a look in File::getSpecialLocation, that’s where it returns the temp directory.
thanks, knowing where exactly to look for the changes is just as good. I’ll figure it out.
I checked File::getSpecialLocation() in juce_mac_Files.mm on the master branch and it it looks fine, returning a folder in ~/Library/Cache for the tempDirectory as on the modules branch.
So it turns out that method is never used for the location of the juceAppLock file but I found this code in juce_posix_SharedCode.h:
Pimpl (const String& name, const int timeOutMillisecs)
: handle (0), refCount (1)
handle = 1; // On iOS we can't run multiple apps, so just assume success.
// Note that we can't get the normal temp folder here, as it might be different for each app.
File tempFolder ("/var/tmp");
if (! tempFolder.isDirectory())
tempFolder = "/tmp";
const File temp (tempFolder.getChildFile (name));
It’s still the same path in the current tip, and I can reproduce my bug with a recent build of the Introjucer application. Everything is fine as long as you always run the Introjucer from the same user account. But when you try to start it with a second account, you’ll get the “Another instance is running - quitting.” method (if in debug mode) even if the other process has quit cleanly, just because of the lack of file system permissions to the juceAppLock file for the second user.
Is there a best way to fix this? Just changing /var/tmp to a folder within the home-directory seems wrong, since it seems to be chosen on purpose.
Ok, thanks, I’ll figure something out there.