The fun iPhone SDK 0xE8000001 error message
radar://6273520 is the appropriate number for the "can't copy the app to the phone" report I made. Hopefully, there haven't been a bunch of "me too" bugs filed. If you did file a "me too" bug, please ammend it with that number. Thank you to the Apple employee who pointed this out to me.
I've been hit by this one as have (it seems) a fair number of other developers. Here is what I've found is the problem in my case.
( radar://6273520 )
After signing (successfully, by the way) my app to install for debugging on the iPhone, the application (for which there is an apparently valid provision profile on the iPhone) will not copy to the iphone with the following errors from Xcode:
MobileDevice: copy_symlink: Could not create symlink on device: 16 MobileDevice: transfer_package: Could not copy /Volumes/Docs/Users/jonathan/svnCheckouts/priv//trunk//build/Debug-iphoneos/.app to PublicStaging/.app on the device: (null)
MobileDevice: AMDeviceTransferApplication: Could not copy package to device via AFC: kAMDUndefinedError
When I delete the application from the iPhone through the XCode interface, then I (ahem) ssh into the iPhone and delete everything in the PublicStaging directory, the app then installs and runs just fine. If I leave either copy of the app there (in the PublicStaging directory or in the directory where it is run by the iPhone), it won't install, giving the 0xE8000001 error that some of us have somewhat inexplicably hit. This happens on my other iPhone (a virgin 3G, in this case) that has *never* been touch by grubby jailbreaking hacking with the same console errors from Xcode.
It looks like the iphone/Xcode stages the application into the /private/var/mobile/Media/PublicStaging folder first, then copies it into the "live" folder. Sometimes (I'm not sure why, yet), the iPhone seems to lock Xcode from writing to that staging directory when an application of a given name is already there. The funny thing is that I can reinstall the OS on the phone and then install the application ONCE (probably because the PublicStaging directory is empty at that time). I wonder what is causing that directory to be unwritable. It doesn't happen for *all* of my apps, though I have had experience with this error suddenly appearing for a given app after having run it on the phone several times in the past. I wonder if rebuilding my certificate chain would help. If I have any time during this or next week (unlikely), I'll do just that and let you all know if that has solved my version of this issue.
Has anyone had success with rebuilding the certificate toolchain in mitigating the misery?
If you're not sure *why* the 0xE8000001 error message is coming up, running Xcode from the Terminal and watching the error messages there might bring some clarity. I would be interested in knowing if my own underlying error is pervasive or if I'm some kind of an outlier here.
I hope that this has thrown a little more light on the error and do please feel free to let me know (privately, if that's more appropriate) if you have had the same or some other error message in the console.
I can be reached at MYFIRSTNAME(AT)MYDOMAIN.com.
This was posted also to the ranchero.com iphone-dev list in partial response to others who are having this problem.
I've been hit by this one as have (it seems) a fair number of other developers. Here is what I've found is the problem in my case.
( radar://6273520 )
After signing (successfully, by the way) my app to install for debugging on the iPhone, the application (for which there is an apparently valid provision profile on the iPhone) will not copy to the iphone with the following errors from Xcode:
MobileDevice: copy_symlink: Could not create symlink on device: 16 MobileDevice: transfer_package: Could not copy /Volumes/Docs/Users/jonathan/svnCheckouts/priv/
MobileDevice: AMDeviceTransferApplication: Could not copy package to device via AFC: kAMDUndefinedError
When I delete the application from the iPhone through the XCode interface, then I (ahem) ssh into the iPhone and delete everything in the PublicStaging directory, the app then installs and runs just fine. If I leave either copy of the app there (in the PublicStaging directory or in the directory where it is run by the iPhone), it won't install, giving the 0xE8000001 error that some of us have somewhat inexplicably hit. This happens on my other iPhone (a virgin 3G, in this case) that has *never* been touch by grubby jailbreaking hacking with the same console errors from Xcode.
It looks like the iphone/Xcode stages the application into the /private/var/mobile/Media/PublicStaging folder first, then copies it into the "live" folder. Sometimes (I'm not sure why, yet), the iPhone seems to lock Xcode from writing to that staging directory when an application of a given name is already there. The funny thing is that I can reinstall the OS on the phone and then install the application ONCE (probably because the PublicStaging directory is empty at that time). I wonder what is causing that directory to be unwritable. It doesn't happen for *all* of my apps, though I have had experience with this error suddenly appearing for a given app after having run it on the phone several times in the past. I wonder if rebuilding my certificate chain would help. If I have any time during this or next week (unlikely), I'll do just that and let you all know if that has solved my version of this issue.
Has anyone had success with rebuilding the certificate toolchain in mitigating the misery?
If you're not sure *why* the 0xE8000001 error message is coming up, running Xcode from the Terminal and watching the error messages there might bring some clarity. I would be interested in knowing if my own underlying error is pervasive or if I'm some kind of an outlier here.
I hope that this has thrown a little more light on the error and do please feel free to let me know (privately, if that's more appropriate) if you have had the same or some other error message in the console.
I can be reached at MYFIRSTNAME(AT)MYDOMAIN.com.
This was posted also to the ranchero.com iphone-dev list in partial response to others who are having this problem.