I was trying to submit my second app update and it failed submission after passing validation. This is the error:
"Unable to create configuration directory:/Application/Xcode.app/Contents/iTMSTransportation.woa/.itmstransporter. Cannot save local copy of remote diagnostic configuration;local path is not writable".
My screen shot of the error cannot be attached. I know it is not a network error at Apple's end because it specified a path in the Application Loader in Xcode. Since the system has read and write permissions here, it cannot be because I changed something. I submitted another app successfully earlier on the same day without a problem (as usual). I am at my wits’ end. Anyone experienced this?
Since there is no “Build for Archiving” in Xcode 5 (like in Xcode), I started with following steps:
1 - From the Xcode Product menu I selected “Archive” item
2 - After the Build, the organizer window appeared in the foreground with my archive in it.
3 - I clicked the “Validate…” button and it executed that successfully.
4 - When I clicked the “Distribute…” button, it started uploading the app but failed and came back with the aforementioned error. I went to the folder to see if any folder in the directory path is locked and also to see who has read and write permissions. It is not me but the system. I did a Disk Permission Repair in Disk Utility but that didn't help.
I then removed the offending file “.itmstransporter.” and tried to submit but got a different error. I put it back and took out the other two (ITMSTransporter.cmd and WOBootstrap.jar” but produced a different error. So I restored the folder to its original contents and returned to where I started - stymied. I have considered installing a new version of Xcode 5.0 but I don't know if that will help.
My OS:Mountain Lion 10.8.5, Xcode 5.0, MacBook Retina (first retina in 2012). Project compiled for iOS 7 in the Build Settings.
Thanks for any pointers.

I had the same issue. I copied the whole "Application Loader" out of the XCode package to somewhere else and after that, uploading from the Application Loader worked fine.
Related
I'm trying to test some features in a production environment, and to achieve this I'm using Google Chrome overrides, that basically allows you to substitute a remote file with a local file.
It sometimes works, but after a couple of reloads it stops working and all the requests start failing, receiving this error in console:
Pay attention: I'm not talking of the full page warning that you see when you access an untrusted website, which has the same error code. I'm talking about the error in console which makes the website unusable.
I say this because I tried googling the error and I only see articles about the warning, that you can easily skip. This is a different subject.
What I tried so far, without success is:
Start chrome with the --ignore-certificate-errors flag
Enabling the allow-insecure-localhost flag in chrome://flags
But they didn't help. How can I tell Chrome to ignore the (inexistent) certificate?
Thank you
Edit
I add an image of my override configuration:
to-override is my local folder. Then I just clicked on a file in the source tab and selected save for override. I found the file in my local folder and I changed it. Changes are applied the first time, but on refresh everything stops working and all the requests fail.
My Chrome version is
71.0.3578.98 - stable - 64 bit
Can you help me get my crashes symbolicated?
In Xcode 7.3, Window -> Organizer -> Crashes, I have crash reports from my latest TestFlight builds. They were built on this Mac, and all the archives with the corresponding dSYMs are in the Archives tab. The app is divided into a number of frameworks and the main app, and many are a mix of Swift and Objective C. In the crash log I can see the name of the frameworks and app listed correctly, but all the entries for my frameworks and app are in hex. UIKit is symbolicated just fine.
When I look in iTunes Connect, it says "Yes" to "Includes Symbols" and allows me to download the dSYMs. When building, the "Debug Information Format" option was set to "DWARF with dSYM". I tried setting "Strip Debug Symbols During Copy"
and "Strip Linked Product" to "No" to see if that made a difference. It didn't.
I cannot find the symbolicatecrash app on my system, not even in /usr/bin or /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash, but I have an older Xcode 5 where I could grab it. However, it does not resolve the symbols anymore.
I have the same problem in Instruments, if I profile my app, UIKit is symbolicated just fine, but my frameworks and app only show hex.
I know there have been a lot of posts about this, but I have going through them a lot from the 7.3 beta period and until now and have not found a solution
The location of symbolicatecrash has changed in Xcode 7.3:
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
After reading this:
https://developer.apple.com/library/content/technotes/tn2151/_index.html
you find out that the App Store is responsible for symbolicating crash reports that come from TestFlight – not Xcode. And it appears the App Store is very unreliable at doing it.
Here's a workaround.
Go to the Archives tab in the "Organizer" window and make sure that for whatever build you need to symbolicate a crash report for, you have clicked the "Download dSYMS..." button over on the right side of the page. This is required if you are uploading in BitCode.
Attach an iOS device so that it appears in the "Devices" window.
Select the device and click "View Device Logs".
Now, go back to the Organizer Window, select the "Crashes" tab and select one of the crashes that did not get symbolicated.
Right-click on it and select "Show in Finder".
Right-click on the revealed .xccrashpoint bundle and select "Show Package Contents".
Drill down into DistributionInfos -> all -> Logs.
Drag any of the .crash files into the left side of the "View Device Logs" pane open in the Devices window.
Wait a second or two for Xcode to symbolicate the crash.
Same here. Having a hard time finding the symbolicatecrash after upgrading to 7.3.
However, you can still use the atos though.
You can find the tutorial here Symbolicate crash in iOS8 with Xcode 6 .1
I do not upload symbols with my application, so the App Store cannot symbolicate for me. I used the following workaround to symbolicate all of the crashlogs that XCode downloads from the store. These instructions are for XCode 8. The paths for the symbolicate crash app will vary from version to version of XCode but the ideas should be the same in each version.
Place your symbols where the symbolicator can find them: Place your symbols (.dsym) file in your Archives directory. You can find this by going to Organizer, context clicking on an archive and choosing "show in finder". Navigate up to the Archives directory (e.g. /Users/USERNAME/Library/Developer/Xcode/Archives) and place your dsym file there. It can be in other locations as well, it's just that I've verified that this one works.
Download the crash logs: In XCode, make sure that you've downloaded the crashlogs for the build you want to symbolicate (Organizer->Crashes, click on your app and then choose the version of your app in the panel to the right of the list of apps).
Locate the crash logs on disk: In the panel that has the App Version and build number, context click on one of the crashes and choose "Show in Finder". Navigate up to the "Crashes Folder" and note this location e.g.: /Users/USERNAME/Library/Developer/Xcode/Products/com.company-name.Your-App/VERSION/Crashes
Setup DEVELOPER_DIR for symbolicatecrash on the command line: Open a terminal window and CD to the crashes directory from step 3 and set the DEVELOPER_DIR like this: cd /Users/USERNAME/Library/Developer/Xcode/Products/com.companyname.Your-App/VERSION/Crashes/
export set DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
(this should be the location of the "Developer" directory inside of your XCode app bundle).
Locate the symbolicatecrash script: symbolicatecrash knows how to find your symbolicate crash logs using the dsym from step 1. Apple moves it around from version to version of xcode. You can find it like this: find /Applications/Xcode.app/ -name symbolicatecrash. In XCode 8, it is in /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
Backup your crashes folder You may want to backup your crashes folder (/Users/USERNAME/Library/Developer/Xcode/Products/com.companyname.Your-App/VERSION/Crashes/)
Symbolicate all of your crashes: Be sure that you are still in the Crashes directory from step 4 and type
for i in `find . -type f -name \*.crash`; do cat $i | /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash --output $i.sym; mv $i.sym $i; done;
This symbolicates each .crash file into an output file and then copies that back over the original, unsymbolicated file.
View Crashes Return to the crashes organizer and view the symbolicated crashes
I tried to copy symbolicatecrash file from xCode 7.2 and pasted it in xCode 7.3 in the following path:
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/
Am using Crasher script to symbolicate the crash reports How to use Crasher
According to the documentation of Xcode 9.0:
The Crashes Organizer symbolicates unsymbolicated logs, if they are
selected, using a local .dSYM indexed by Spotlight. (22550064)
You can check out more on this in Xcode's Documentation.
Solution: Turns out this win 8 machine was hiding known file extensions. Both of my test files ended up being testing.txt.txt and testing.pdf.pdf which of course would fail when I tried to find testing.txt.
For some reason any part of the VBA api that does file operations fails on my system running windows 8, but succeeds on windows 7 (both running Access 2013).
I was trying to use the FollowHyperlink method as a simple way to open a .pdf file. So I started simple:
FollowHyperlink "C:\TestingFolder" - Yields an explorer window opened to the path (great!)
FollowHyperlink "C:\TestingFolder\foo.pdf" - Yields Error 490 Cannot open the specified file
So then I tried the Filelen function and got another error that it could not access the file.
I ended up at the conclusion that any operation that actually accessed a file would fail, likely due to some security setting. The fact it works on Windows 7 and not 8 seems to indicate that something at the OS level may be at fault.
Resolutions I tried:
Ran Access explicitly as administrator
Moved files into user directories and out of root
Went into the Access Trust Center and disabled all security measures (temporarily)
Tried different file types (.pdf, .txt)
Your problem is not the Windows API, but the installation of the software. The FollowHyperlink, uses the system registry where the file type association is involved. If PDF files are associated with Adobe Reader and you have it installed and made PDF to be, by default open with Adobe then you will not have a problem. However if your system lacks the program that could open a file with a "creepy" extension then it will fail miserably.
Your solution is to find the appropriate program to open the file. Then use the code, it will open the appropriate file with its associated program.
Turns out this win 8 machine was hiding known file extensions. Both of my test files ended up being testing.txt.txt and testing.pdf.pdf which of course would fail when I tried to find testing.txt.
I ran into a problem creating a new project in Cocos2d-x 3.1.1 (or 3.0 - it happens at both versions).
When I'm running the build script in console (Windows 8 - console with admin privileges) an WindowsError pops up (check the image below).
http://i.imgur.com/Ixg4jEE.png
I can set up the COCOS_CONSOLE_ROOT manually, but it does not help with the Error 5.
I tried setting the 777 priviligies an all cocos2d-x folder and subfolders, but it does not help.
Anybody had the same problem? Any solutions out there?
On Windows you should not put manually installed programs and tools under C:\Program... (english: C:\Program Files) because that's a folder where only apps with a proper installer should go. Otherwise you will keep having permission issues. Apps are not allowed to write to that folder or any of its subfolders.
Since cocos2d-x isn't an app, it can't redirect its output to the proper AppplicationData folder as is mandated by the operating system. Not being able to write or modify the program folder's contents (except during installation) is a security feature in Windows that you can't (or shouldn't) bypass.
To fix this simply extract cocos2d-x in a folder that both you and apps have full read/write permission. Normally this would be in your Documents folder, but Desktop would also work and probably just any folder on a drive that you created, for instance C:\cocos2d-x.
Due to this line:
_winreg.SetValueEx() ...
the actual problem looks like to be with registry access, rather than with file permissions.
Make sure you actually running console as an admin, by:
searching cmd in Windows search, or just creating a shortcut to it to desktop
right clicking to cmd.exe and choosing "Run as administrator"
Make sure you don't have registry access block in any way: like blocking in group policies, some "security optimization" software and viruses and antiviruses.
Make sure your python version is 2.x. Python 3.x is not supported.
Anyway, this 'setup.py' step is optional for using cocos2d-x and you can live without running it at all.
I'm on Windows. My Nitrous desktop app wont sync files. It says
"Error Warning the previous run of unison terninated in a dangerous state."
How can I fix this?
Thanks
The file transferring may not have completed properly. Try restarting the Nitrous Desktop app and try again.
If you run the app from the command line then you should see a full log message details on which files it is having issues with. If the app continuously displays this error then you may want to try removing the files which are causing the warning.
Here is a full explanation via Yahoo Groups:
There is a small window of danger while Unison is finishing
transferring a file, when the old file has been moved to a temporary
location but the new file has not been moved where it belongs. This
message is telling you that Unison got interrupted just at this moment
the last time it ran. You should check the file it's warning you
about, then delete the DANGER.README file and try again.