locked
DownloadOperation.startAsync: the system cannot find the file specified

    Question

  • I have been observing some strange behaviour when using BackgroundTransfer facilities to download files: every few hundred files, after calling startAsync on a DownloadOperation, it will fail with the message "The system cannot find the file specified." - Yet when I look at the target file, it is there and indeed has even been downloaded successfully.

    Did anyone else experience something like this before? As recommended by some samples, I also keep a map of files that are downloading to not download the same file twice.

    Wednesday, May 29, 2013 11:29 AM

All replies

  • Hi,

    Thanks for posting!

    I think you can see some articals in MSDN Lib.Microsoft support some very good sample and code for us.About you question,you can see this link and threads:

    Exception handling in async calls

    DownloadOperation class

    Quickstart: Downloading a file (Windows Store apps using C#/VB/C++ and XAML)

    hope this helps!

    Monday, June 03, 2013 2:26 AM
  • Unfortunately, that doesn't really help me.

    What I'm experiencing is an exception being thrown although everything worked just fine. What I now did was to add a special handler for this exception which will check the hash of the downloaded file and if it matches the expected hash, just discards the error.

    So far, every single one of this "cannot find the file specified" errors could be discarded by this handling. The error occurs once every ~500 download operations.

    Monday, June 03, 2013 7:26 AM
  • I am seeing the same errors. After starting a bunch of DownloadOperations some of them will (seemingly random) fail, but when you look on the file system the files are actually there and have content. This makes it somewhat unreliable to use BackgroundTransfer for handling a lot of downloads

    In our case we need to download a bunch of resources and bundle them as a children's book for reading, when one of the files fails to download we mark the book as failed and need to download it again. Our best bet would be to ignore the DownloadOperation errors, but that doesn't seem the right way.

    Monday, July 08, 2013 8:49 AM