Adding PNG files to project results in codesign error

I'm trying to add a small PNG file to my project and the build resuts in a codesign error:


Debug/Example.app: resource fork, Finder information, or similar detritus not allowed
Command /usr/bin/codesign failed with exit code 1


I can add the same image as JPG format and the project compiles/runs just fine.


What would cause this issue ... does Xcode for some reason dislike PNG images? I found this thread that sounded similar: https://forums.developer.apple.com/thread/68489

but would like to understand what cuases this issue before I start running unknown utilities to fix things I can't explain.


Thanks,

Replies

>does Xcode for some reason dislike PNG images?


Loves them usually, at least in my experience. I can imagine a case where a file would bork a build, but not codesiging...that part of the process should care less, I think.

Seen Tech QA 1940 yet?


https://developer.apple.com/library/content/qa/qa1940/_index.html

>I tested with other PNG files and no issue, so I have to think it has something to do with the files created by this app.


Seems odd, but in that case, I'd have to agree. Have you looked at one of them in the Finder to confirm there isn't a hidden double suffix being added when they're generated?



Take one of the bad actors and open it in Preview, then save with a new unique name, keeping the .png suffix/type. Add that to the project and test.


>Using xattr to compare attributes, all the files have extra attributes.


Like what?


Is there a chance Paintbrush is assigning different/specific permissions? What type of png? Are you adding transparency....alpha channel....animated...live?


What version macOS on which Mac?


Just for the record, I don't think this is a specific code signing fail cause/effect, just that the build fails when trying to process that asset, with the end result being an aborted code signing because the process never gets that far. 'similar detritus not allowed'...I believe, however.

this has been a known xcode bug for a while, i file one about three weeks ago. i've seen other reports elsewhere going back a year or so.


as others said you need to remove the extended attributes from images and there is a somewhat related bug that if you link in files, you get a blue folder not a yellow one, chances are 40% xcode will fail to build or crash. xcode has issues with how osx creates extended attributes on symbolic links hard or soft, i tried both.

Thanks. I updated Xcode tonight, but same issue. As previusly indicated removing all attributes doesn't seem to help.


It's not a huge issue to me now that I can oowork around it. Perhpas I should file a bug report and see if I can send an example file for analysis.

In another related link I found this tidbit:


>> execute "xattr -rc ." both in DerivedData directory and Project directory works


For kicks I did `xattr -rc .` in my project folder, clean and rebuild and it works. Just to double-check I created a new PNG, created new Xcode project, tested for the failed build again, then went hunting around to see what actually clears this up. Once the image was added to the project I found the copied image in my project/project folder, and `xattr -rc file.png` followed by project clean and build seemed to result in success. Prior to this I had been creating files and doing xattr modification outside of the project folders and adding the test images in followed by build.


It's also possible some of my tests were polluted by cruft sitting around that needed to be Clean'ed before the build test. Looks like I can consistently copy in tiff and png files if I make sure the copy in my project folder is attribute free and also ensure project is cleaned and attribute free prior to build.


Still odd that gif/jpg/bmp images from the same program added in work fine attributes and all.


Thanks all who commented here!

This post, final comment by LibeCompta Sep 10, 2016 had the clue that lead to my solution, except I just started in my project folder:

https://forums.developer.apple.com/message/177523#177523

Looks like all along it was an extended attribute issue somehow tirggered by use of the file name extension tif/png.


Thank you all for commenting on this thread!