I think I may have found the reason why under Sierra unsaved web projects runs do not delete the debug run. They take place in Temporary.
Once I have saved in another place, let us say Downloads, the debug build is deleted as expected.
Apple may have changed something about the way documents can be deleted in Temporary. Maybe until the app that created the document is quit, they are locked ?
No, that is not that. Saving elsewhere does not alleviate the issue. Neither does quitting the IDE and relaunching.
Since a banal script can delete the debug build folder, I am forced to conclude the IDE does not delete that folder correctly. Maybe time to shell to RM like the script does, instead of dragging this bug any longer…
I’ve been having this issue too and that with builds happening in the same directory as the project. It’s an annoyance but not overly once you know about it.
Happens way more on web apps than desktop but I’ve had it happen there too - just not as often. Let me know if there’s anything I can do to help figure this out.
I assure you the problem is constant here, on a 2011 iMac. The only way to alleviate it is to use a build script that shells to rm to remove the folder.
Please dont mistake me saying “I cant reproduce this” for “I dont believe you”
There could be any number of reasons that cause the debug executable to not be deleted
IF you run lsof on the debug executable does anything (like spotlight) hold on to it and mark it busy so our efforts to remove it fail
Thats useful information
Its possible that by the time you run the script to remove it those things are no longer holding on to it
So rm works (although rm can have some fun oddities of its own since rm is not the same a unlink)
But us trying to do it as soon as the debugger quits fails
It’s not a MAc-only problem, i have the same on Windows 10 on a real pc, not a VM.
AFAIK this is introduced somewhere in 2016 r1 or r2. And it’s not an incident but it happens allways with webapps, don’t know for desktopapps.
lsof returns nothing at all. The prompt comes back, and that’s it.
But, permissions are odd :
Me : Read & Write
staff : Read only
everyone : Read only
I doubt very much it is a question or synchronization, since the folder remains here and prevents a new run, even if I run again hours later.
In terms of project size, whether I do it on the small project I used to come up with the non scrolling control (2.8 MB), or the RubberViewsWE project (3.6 MB), same punishment. I don’t have bigger projects available.
I know it would be better for you to be able to reproduce it.
What I know is that using rm works, and the IDE chokes on the same folder.
This script from Beatrix Willius works fine when placed before build :
[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]
But that is still a bandaid on an issue that should be fixed.
[quote=289383:@Andre Kuiper]It’s not a MAc-only problem, i have the same on Windows 10 on a real pc, not a VM.
AFAIK this is introduced somewhere in 2016 r1 or r2. And it’s not an incident but it happens allways with webapps, don’t know for desktopapps.[/quote]
I just tested on my own machine under Windows 10 Anniversary Edition build 14393. No such issue with either web or desktop.