Icon files inside script bundles getting corrupted

Script Debugger
#1

The icon files I put inside script bundles keep getting corrupted.

(I suspect it may relate to changing git branches, but I am not sure.)

I’ll deploy an app and my custom icon won’t show. I open the original .scptd bundle in Script Debugger, click on the icon in the “Resources” folder shown in contents on Script Debugger’s resources tab, and if I just hit space to Spotlight Preview it, I just get an endlessly spinning loading icon in the preview window.

I can drag the original icon over, replace, and it will preview fine, and I can export the app and get the icon. But sooner or later, the copy in the original bundle always ends up going bad again, and then the next time I deploy the icon doesn’t work, the .app just shows up with a default script icon.

Here’s an example file with the corrupted icon.

#2

Can you be a bit more specific in what’s happening? The sample opens as damaged here.

As .scptd files are document files, I’m not sure they strictly support custom icons. They won’t when saved from Script Debugger, although the icon will be included and used when it is exported as an applet.

#3

Yes, so we aren’t expecting a custom icon to display on the .scptd. The .scptd lives on git, and then we run a deployment script that exports it as a code-signed, run-only, .app.

So I make a .scptd, go to the resources sidebar in Script Debugger, drag a custom icon from Finder into the Resources Folder for the .scptd in Script Debugger, and select that icon in the drop-down in Script Debugger.

Then when I deploy as a .app, the .app has the custom icon and everything’s great.

But then sometimes, when I next open the .scptd off git, make some changes to the code, and deploy, I notice the deployed copy no longer has the custom icon. This happens frequently.

So I open the .scptd, take a look. The icon file still shows inside the resources folder in Script Debugger, and it’s still set on the dropdown. But if I try to open that .icns file, it won’t open… if I drag the original back to in from Finder and choose “replace,” then it’s fine again. I can re-deploy and the icon’s back. But I have to do this all the time - more often than not with our applications that have custom icons, when I come back to them, the icons file doesn’t work anymore.

The .zip I uploaded of the example script with a corrupted icon - it’s weird, I just decompressed it here, double-clicked, and it opened right up in Script Debugger.

If I go to Finder and look inside the bundle at the .icns file for a corrupted one, the file size is exactly the same as the original, but Spotlight won’t preview it, and if I double-click to open, Preview tells me:

“The file “cleartemp.icns” could not be opened. It may be damaged or use a file format that Preview doesn’t recognize.”

So I suspect something about git/Script Debugger - I was hoping when you heard this, it would ring a bell with whatever was happening where Script Debugger thought our code was corrupt when we switched branches, that maybe it was a similar thing with the .icns file, but apparently not.

I ran a text diff on the non-functioning and a functioning copy of the same .icns files and it reports the contents are identical… so it must be something metadata related? I’m scratching my head.

#4

Here’s an archive containing just a functioning and corrupted copy of the same icon. Maybe you’ll see something I don’t about what’s different?

Good and bad .icns.

#5

I see this in the bad one’s attributes: com.dropbox.attrs. That rings a bit of an alarm bell here.

#6

That’s interesting. The .scptd file lives on my local drive, not Dropbox. In it in a git folder, but not Dropbox.

The script that exports it as a .app does export the app to a Dropbox folder, but I’m surprised that a “save as” to Dropbox would be corrupting the copy of the icon file in the .scptd that doesn’t live on Dropbox.

I suspected Dropbox first when I saw the icon not working after deploying a new copy of the .app to Dropbox. But then when I opened the .scptd that it was deployed from - which isn’t on Dropbox - and saw that the icon didn’t work there either, I thought it couldn’t be a Dropbox problem.

Can doing an export from a file that’s not on Dropbox to Dropbox corrupt resources in the original?

#7

It’s interesting, I used xattr -d to remove the com.dropbox.attrs on the bad one and it still doesn’t work.

I completely agree that this implicates Dropbox, I just don’t understand how, when the copies of the scripts where it keeps getting corrupted aren’t on Dropbox. Dropbox somehow corrupts a copy not-on Dropbox when it’s duplicated to Dropbox? I guess? I can’t wrap my head around what’s happening.

#8

I ran this on your samples:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions

current application's NSFileManager's defaultManager()'s contentsEqualAtPath:"/Users/shane/Downloads/good and bad icons/GOOD/cleartemp.icns" andPath:"/Users/shane/Downloads/good and bad icons/BAD/cleartemp.icns"

It returns false.

#9

So there is some actual difference to the contents of the files, not just the metadata? Just something that’s not detectable by comparing the contents as text.

Still any idea what could be causing it? I’d be surprised if GIT is just flat-out corrupting file contents, as it’s so widely used.

#10

I suppose, since all my saves/exports are done via script anyway, I can just have the save script check to see if there’s a custom icon, and if there is, replace it with a known good copy from another directory before saving every time. Don’t “fix” it, just bypass the bug.

#11

I don’t know if this shines any light on anything, or is just additional confusion.

I just edited and deployed an app with a custom icon. I saved and closed the script. Then I noticed the icon was missing from the deployed copy again, so I re-opened it and dragged a good copy of the icon to the Resources folder in Script Debugger like I always do, choosing “replace” when it asked me. Selected the icon file in Script Debugger and hit space to spotlight it, and it previewed properly. Hit command + S to save, and I get:
Cannot Save Document
File not found (fnfErr:-43)

That’s new…
I since the only thing I changed was replacing the icon file, I go to the sidebar in Script Debugger, select it, right-click, choose “Delete,” say OK on the resulting dialog:

Do you wish to delete these files and/or folders?

  levelsetter.icns

This operation cannot be undone.

Yet the icon still shows in the sidebar… I can’t make it go away or save the document.

I tried a “save as,” which didn’t work either.

I checked the package contents in Finder, and it doesn’t exist in the bundle anymore.

I tried dragging it back into the Resources Folder in Script Debugger from the Finder, but nothing seems to happen.

I’d send you the script, but I can’t save it to send…

#12

Now this is interesting.
I flipped to my git client, Fork, and it was showing me changes to the script I was working on… it’s attempt to show me the changed files looks like this:

image
image1346×1170 128 KB

Can’t even show you the whole thing… it’s at least 20 levels deep… there are at least 20 copies of the entire script saved inside itself.

It’s not just a git bug, I checked in Finder and there really are over 20 copies of the whole bundle nested down.

Here’s the path name at the very bottom level:
/Users/work/Documents/Fork Github/art-scripts/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Contents/Resources/ArtBot Level Setter.scptd/Conten

It literally ends with an folder just called “Conten”

1 Like
#13

That’s the result I’d expect if you accidentally dragged the .scptd file into its own Resources folder, instead of the .icon file. Possible?

#14

Ah, the screen lagged and something went wrong one time I was dropping the icon in, so that’s probably what happened there. This cascade of nested files isn’t generally the case with the corrupted icon.

So still no idea why it’s corrupting, and if it’s related to Script Debugger, git, somehow Dropbox although it shouldn’t be involved, or something else entirely.

But since I can Script around the bug, whatever it is, maybe I should just leave it a mystery and spend my time elsewhere.