Can't access iOS file about backgrounddownload HOT 16 OPEN

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

from backgrounddownload.

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

from backgrounddownload.

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

from backgrounddownload.

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.

from backgrounddownload.

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

from backgrounddownload.

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

from backgrounddownload.

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.

from backgrounddownload.

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

from backgrounddownload.

Which iOS version are you using?

from backgrounddownload.

13.2.3

from backgrounddownload.

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)

from backgrounddownload.

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.

from backgrounddownload.

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"}}}}

from backgrounddownload.

@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.

from backgrounddownload.

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.

from backgrounddownload.

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.

from backgrounddownload.