This problem started as an issue with a build script but I think I’ve resolved it…
Sharing this here for comment and see if there is anything else I should do…
I am on 10.9.4 using Xojo 2014 r2.1
Create a new Mac OS X desktop project…
Save it to the desktop (call it yournewapp for example)
Run the app and leave it open…
Switch to Terminal
type: defaults read [path to yournewapp.debug].app/Contents/Info.plist
You’ll see all the normal plist data for a basic Info.plist file. So far so good.
Switch back to your app and the quit it.
You’ll notice that Xojo was unable to delete your debug app from the desktop. Instead it’ll be left in place but everything except the Info.plist file is deleted.
This will lead to a problem if you try to run that project again. You’ll need to delete the app first otherwise you’ll get an error (104)
It seems to be an issue with aggressive plist caching. I’ve never had this before.
After you quit the app - you can do a lsof and grep for your app name. You’ll see cfprefsd still has your Info.plist file open
To address the problem I’ve had to issue a killall -u cfprefsd
Not sure of the impact of doing this, but it seems OK so far.
This issue might effect anyone using a post build shell script to adjust Info.plist files - I have been doing that for years and never had a problem before, but it seems now. I might need to add the workaround or think again.
I don’t think this is Xojo’s fault, since it’s cfprefsd that won’t release Info.plist
Xojo (or any app) won’t be able to delete or write over the file because it’s being used. And that’s where your problems come from.
Agreed. I don’t think it is Xojo’s fault at all.
Just putting it out there incase anyone has come across this before and has any alternative approaches.
Also - not 100% sure of the potential impact of killing the daemon. So far its’ working though.
@Norman, you are correct. That’s what comes from using organic memory. Here is the correct script:
[code] dim dbg as String
if debugBuild then dbg = “.debug”
dim appNameForShell as string
appNameForShell = PropertyValue(“App.MacOSXAppName”) + dbg +".app"
appNameForShell = replaceall(appNameForShell, " ", "\ ")
dim CountSlashes as Integer = CountFields(ProjectShellPath, "/")
dim ProjectName as string = NthField(ProjectShellPath, "/", CountSlashes)
dim ProjectPath as String = Left(ProjectShellPath, Len(ProjectShellPath) - Len(ProjectName))
dim theCommand as String
theCommand = "rm -rf " + ProjectPath + appNameForShell
dim theResult as String
theResult = DoShellCommand(theCommand)
if theResult <> "" then print theResult
function getShellString(theString as String) as string
Return ReplaceAll(theString, " ", "\\ ")
[quote=128031:@Beatrix Willius]Why don’t you get the path to your app with one of the build constants? That would be
dim appPath as string = currentBuildLocation + "/" + shellEncode(currentBuildAppName)
This way you don’t have to fear anything and you can move the project around.[/quote]
I did try to use those but had no luck and was in a hurry to sort the issue so I just hard coded the path. I don’t move projects around anyway, so not had any issues. I’m familiar with the shell so it was the path of least resistance at the time.