Xojo - unable to delete my debug.app - aggressive plist caching

General
1

Hi…
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

Try this…
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.
Quit Terminal
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.

Comments welcomed.

dave

2

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.

3

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.

Thanks

4

We’ve seen mention of cfprefsd being aggressive in caching even with relation to Xcode projects
Just google for cfprefsd and you’ll find lots of chatter about it

5

I also see this issue when using a build script to add retina compatibility to the plist.

I’ve got around the problem by adding a build script that runs before the main build that uses a shell command to delete the debug build.

The script is:

[code]App = “/Volumes/Macintosh\ HD/Users/FULL/PATH/TO/YOUR/DEBUG\ BUILD.debug.app”

Call DoShellCommand("rm -R " + App)[/code]

Ensure this is placed before the build stage. Also be VERY sure you get the path to your debug app correct or you run the risk of deleting something important!

It’s crude and a bit hacky, but it seems to work OK.

6

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.

7

some of those meta constants don’t exist BEFORE the build

8

@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, " ", "\\ ")
end Function[/code]

It’s a life saver!!!

9

[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.

10

Did you check my above complete script? This works 100%. The line you quoted won’t work here because you are before build.