BackgroundDownload icon indicating copy to clipboard operation
BackgroundDownload copied to clipboard

Can't access iOS file

Open LukasRoper opened this issue 5 years ago • 16 comments

Hi,

Can you provide more details on how to access the final downloaded file on iOS please?

I'm able to complete the download but it seems the file isn't actually being copied from the temp directory to the final directory.

I added a boolean value to determine if the replaceItemAtURL operation completes and it returns false.

[code=CSharp] NSFileManager* fileManager; NSURL* destUri = GetDestinationUri(downloadTask.taskDescription, &fileManager); [fileManager replaceItemAtURL: destUri withItemAtURL: location backupItemName: nil options: NSFileManagerItemReplacementUsingNewMetadataOnly resultingItemURL: nil error: nil]; UnityBackgroundDownload* download = [backgroundDownloads objectForKey: downloadTask]; download.status = kStatusDone;[/code]

Hoping someone who's familiar with iOS might have an idea about what is wrong?

I'm using Unity 2019.1.14f.

Thanks,

LukasRoper avatar Mar 21 '20 23:03 LukasRoper

Can you show your C# code? Including the destination for your file.

aurimasc avatar Mar 25 '20 12:03 aurimasc

I am having the same issue.

My C# code is this: _backgroundDownload = BackgroundDownload.Start(new Uri(url), MakeBundleRelativePath(moduleData.BundleName)); and the destination path is: "moduleBundles/aed.assetbundle"

I debugged the iOS plugin and found that in UnityBackgroundDownloadStart(void* req, const char16_t* dest) in BackgroundDownload.mm, dest is NULL, even when I pass in a string literal to BackgroundDownload.Start.

The download completes, I can see the progress increasing, however the file is nowhere to be found. The same code works on Android. I am on Unity 2019.2.6

virtualboys avatar Sep 14 '20 18:09 virtualboys

What does the MakeBundleRelativePath() do? And, when debugging, make sure you build and run XCode in Debug mode (Unity defaults to release when exporting).

aurimasc avatar Sep 15 '20 08:09 aurimasc

MakeBundleRelativePath just returns "moduleBundles/aed.assetbundle". After debugging in debug mode, I see that dest in UnityBackgroundDownloadStart(void* req, const char16_t* dest) is actually set correctly. However the file still does not exist when the download completes. I used XCode to show the container for my app and do not see it anywhere.

virtualboys avatar Sep 15 '20 14:09 virtualboys

Try debugging the completion code and see where the file is saved.

aurimasc avatar Sep 15 '20 14:09 aurimasc

replaceItemAtURL completes with an error: NSCocoaErrorDomain 513 destURI is: "file:///var/mobile/Containers/Data/Application/A75442A2-A4C1-41DC-A861-7E459D546CFB/Documents/moduleBundles/burns.assetbundle"

virtualboys avatar Sep 15 '20 14:09 virtualboys

Check the path it is trying to save to. Does directory exist? If not, you probably need to upgrade, I see in the code, that the directory should be created prior to download.

aurimasc avatar Sep 15 '20 14:09 aurimasc

The directory does exist. I also tested with the destination being in the root Documents directory and have the same issue.

virtualboys avatar Sep 15 '20 15:09 virtualboys

Which iOS version are you using?

aurimasc avatar Sep 15 '20 15:09 aurimasc

13.2.3

virtualboys avatar Sep 15 '20 15:09 virtualboys

I thought I commented but I fixed this a while ago. I think there's an odd discreprency between provinding the full file url for Android and doing the same for iOS. On iOS it seems to attempt to prepend part of the directory. I amended the .mm file's code (green being new lines, red being removed) image

LukasRoper avatar Sep 16 '20 13:09 LukasRoper

What do you mean by "I think there's an odd discreprency between provinding the full file url for Android and doing the same for iOS"? The destination file path must be relative path and will be saved under Application.persistentDataPath.

aurimasc avatar Sep 16 '20 14:09 aurimasc

The log on XCode has more information. Seems like there is an underlying error?

2020-09-16 17:56:21.353818-0400 emanmomot[5820:406849] Failure Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “aed.assetbundle” in the folder “Documents”." UserInfo={NSFileOriginalItemLocationKey=file:///var/mobile/Containers/Data/Application/E0AED388-FDD2-4444-937C-DF0C132D0287/Documents/aed.assetbundle, NSURL=file:///var/mobile/Containers/Data/Application/E0AED388-FDD2-4444-937C-DF0C132D0287/Documents/aed.assetbundle, NSFileNewItemLocationKey=file:///var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSUnderlyingError=0x281d96760 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “CFNetworkDownload_c5SXp9.tmp” in the folder “com.emanmomot”." UserInfo={NSURL=file:///var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSFilePath=/var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSUnderlyingError=0x281d96730 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}}

virtualboys avatar Sep 16 '20 21:09 virtualboys

@aurimasc So the directory I would provide would be Application.persistentDataPath + the local relative directory I wanted to save it to. So I think on Android this worked without any sort of hitch. However when I did the same on iOS, I think the Application.persistentDataPath would include the full path which then the DestinationURI function would also prepend some of the path on to as well. My memory is a little vague now but I remember that being the crux of my problem anyway. Might not relate to this issue as obviously I originally posted a while ago.

LukasRoper avatar Sep 16 '20 22:09 LukasRoper

No, the path you have to provide must be relative. If you pass "xxx/yyy.zzz", then the directory named "xxx" will be created under Application.persistentDataPath and then file will be saved in it. Note, that on iOS on different app runs the absolute path does change, so an absolute path cannot be used, after app is killed and relaunched, the destination folder is no longer accessible to your app.

aurimasc avatar Sep 17 '20 07:09 aurimasc

So, it seems this issue was related to how I was signing the app. I guess using a dummy testing certificate prevented the app from having the permissions it needed to read & write the download files or something. When I used my company's provisioning profile & signing certificate everything worked properly.

virtualboys avatar Sep 29 '20 19:09 virtualboys