1

I'm using NSURLSession to download a list of files in my app.I have support for background downloading and is working correctly.But some times when the WiFi connectivity is lost while the app is in background,some files remain in the temp directory(com.apple.nsnetworkd) and is not getting removed.So when i download a new set of files these files still remains in the directory.This situation repeats on WiFi failures and the set of files keeps accumulating.Any way to solve this issue? Will there be any problem if i try to remove these files manually?

If WiFi connection is active then everything works fine and tmp directory is cleared automatically.

  • Probably related: http://stackoverflow.com/questions/19184490/nsurlsession-background-download-resume-over-network-failure?rq=1 – CouchDeveloper Apr 04 '14 at 10:21
  • @CouchDeveloper The question you referred is about resuming task in background even after WiFi failure.Im not implementing that.My question is specific for clearing the unfinished downloads due to wifi failure. – Jacob Davis Cherussery Apr 04 '14 at 10:27
  • Your question misses a lot of details. What do you mean with "support for background downloading"? What is the error you get? How did you setup your session and how did you create your task? So, please post your code. – CouchDeveloper Apr 04 '14 at 10:32
  • I am making use of apples sample code for NSUrlSession. The only difference is that I am using multiple file for downloading. Now I just took the app to background and turned the WIFI off. Then I brought my to foreground but some of the tmp files are still in the tmp folder (com.apple.nsnetworkd) in Cache folder. Then I continued the same scenario with WIFI on. this time its adding as a new task. and the old files remains there. Is there any way to solve this? – Jacob Davis Cherussery Apr 04 '14 at 10:38
  • @CouchDeveloper Here is the link for Apple's sample code.https://developer.apple.com/library/ios/samplecode/SimpleBackgroundTransfer/Introduction/Intro.html – Jacob Davis Cherussery Apr 04 '14 at 10:49
  • I tried with this code. – Jacob Davis Cherussery Apr 04 '14 at 10:50
  • Do you also get a spurious tmp file when you use the original Apple sample and switch Wifi off and on? When resuming happens, does it actually _continue_ the download, or does it _restart_ the download? – CouchDeveloper Apr 04 '14 at 11:02
  • @CouchDeveloper The tmp file created by the above mentioned process stays there and the next time i begin download a new file is initiated to start the download.The old one stays as it is.The problem is when i am trying the sample with a large file,it may download 20-30 MB and WiFi goes off it stops and the tmp file with the size stays there.When i start downloading again the uncompleted download file stay as it is and new download is initiated.You can check out with the sample. – Jacob Davis Cherussery Apr 04 '14 at 11:12
  • Maybe the tmp file still exists, since the task could possibly be continued with `downloadTaskWithResumeData:`. It's difficult for the system to decide *when* to delete tmp files, since they *might* be useful again later, when an app resumes a failed download. But I would expect that the system will *eventually* delete tmp files. – CouchDeveloper Apr 04 '14 at 12:52
  • @CouchDeveloper Ya but instead of resuming from the file it is creating a new one for the same download.It causes space wastage and thats what im complaining about.Have you checked with the sample code. – Jacob Davis Cherussery Apr 04 '14 at 12:54
  • That is, you expect the system to automatically continue a failed download? Please consider this (from the docs): _"If a transfer fails, the session object provides an NSError object either to your delegate or to the task’s completion handler. In that object, the NSURLSessionDownloadTaskResumeData key in the userInfo dictionary contains a resumeData object."_ – CouchDeveloper Apr 04 '14 at 12:56
  • No i dont want to continue a failed download.Have you run the sample code? – Jacob Davis Cherussery Apr 04 '14 at 12:57
  • Ok, but the system doesn't know this. It seems logical that the system doesn't delete tmp files immediately after a transfer fails, otherwise one couldn't continue them. But tmp files will be deleted *eventually* by the system. – CouchDeveloper Apr 04 '14 at 13:00
  • @CouchDeveloper i got your point but instead of starting from tmp file ,it is starting a new download thats what causing me the issue.it gets worse when i download 50-60 files and if wifi goes off some of them are cleared from cache but others stay there.will manually clearing the folder solve the issue. – Jacob Davis Cherussery Apr 04 '14 at 13:06
  • When you start a *new* download, it _of course_ uses a new tmp file. This is expected. I think you have two options: either continue a failed download which should use the existing tmp file, or let the system eventually delete it. Well, I believe it's also safe to delete those tmp files which you don't wan't to resume. But since this an internal Apple thingy, I would suggest to ask this in the Apple Developer Forum. – CouchDeveloper Apr 04 '14 at 13:12
  • Ok.I have posted it in Apple developer forum but did'nt get a reply.I'll try the resume part in case of failure. – Jacob Davis Cherussery Apr 04 '14 at 13:14
  • I'll take a look too, in the forum. A sound answer my take a while, since it can be answered only from Apple staff, and they hang there voluntarily. – CouchDeveloper Apr 04 '14 at 13:17
  • I have the link for the post https://discussions.apple.com/thread/6059242 – Jacob Davis Cherussery Apr 04 '14 at 13:25
  • You should post this question to the official Developer Forum at `devforums.apple.com`. There are a few related questions and a workaround: https://devforums.apple.com/message/934777#934777 – CouchDeveloper Apr 04 '14 at 16:51

1 Answers1

0

Trying resuming the task or don't worry if you still find it ios to handle it when required to free the space

From Doc A file URL where the temporary file can be found. Because the file is temporary, your delegate method must either open the file for reading or move it to a permanent location in your app’s sandbox container directory before returning.

mkumar
  • 111
  • 1
  • 10