URL::DownloadTask::Listener::finished is called with file handle still open

Windows
1

I am downloading a file to a temporary directory using URL::downloadToFile and then renaming it in my finished callback, which works fine on macOS, but in Windows it appears the file handle must still be open as any attempt to use File::moveFileTo fails, as do any attempts to File::deleteFile.

I solved this by instead using File::copyFileTo and then waiting a while before deleting the temporary file in a Timer::callAfterDelay, but it would be nicer if the same code using moveToFile worked on both platforms.

When I have some time I can create a demonstration PIP to show the issue if required.

2

Another issue with URL::downloadToFile is the it connects to the server on the main thread, and then downloads on a background thread. So it can block your main thread for up to 30 seconds or so. It’s already creating a thread, so it would be nice if it used it for the connect as well.

1 Like
3

I noticed this issue too and resorted to a Thread::launch lambda to start the download. I guess the reason for the synchronous nature of the existing code is knowing that the connection failed if the returned DownloadTask is a nullptr?
edit: having said that, if a URL::DownloadTask::Listener is provided then it really would be nice if the connection was made on a thread, since you can determine success from the finished callback.

4

I’m also having an issue with this.
I’m downloading a file and in the “finished” callback I try to open it with “startAsProcess()”.
It works on Mac but on Windows nothing happens because the file is “being used” by my app.

Edit: found this thread.

5

Seems to me, instead of just flushing the fileStream, releasing it should solve the issue then, or is there a reason to hang on to it?

should be:

fileStream.reset();
1 Like
6

I can confirm that fileStream.reset() works, I believe this should be changed -> @t0m

7

Thank you for reporting!

1 Like