iOException 32 on Windows URLConnection?

I have created a wrapper class for URLConnections that works nicely on both macOS and Windows.
I can add connections to a control that keeps track of them and fires events based on their upload and the server response download status.
When the fileReceived event fires, I can open the XML, read and process responses, and the control deletes the temporary file.

All great, except for it has stopped working on Windows when I added another download type (type is just a string property of the URLConnection subclass I use).

Because I read somewhere here that using temporary files should be more reliable (but don’t know the source and current validity of this statement anymore), I am using downloads into the temp folder. That file for this type (called AccountCheck.txt) arrives (although progress property on Windows is Infinity), exists and has valid content when I view it manually.

When I try to open it with a TextInputStream, Windows fires an iOException 32 – file is in use by another process –, which does not make any sense to me. It are exactly the same methods and event handlers that work for every other file reliably. And the filereceived event should return the file free from every possible background thread, shouldn’t it?

Any hints why this could fail? Thanks a lot!

It might be that something outside your app is locking the file (virus checker etc.) as its a different file type (if I correctly understood what you’re doing), grab a copy of Process Monitor, filter by the folder where your temp file is placed and see if anything else is touching it as its created. It might be that you need to wait for that process to finish with the file before you open it.

Thanks, Julian. I handled it now by a direct download into memory.
Where I have rather long downloads, the folder item download is working luckily. Could indeed be an internal Windows mechanism – no additional snake oil installed. Strange still, there are other .txt files I can download without problems.
Meanwhile, I found another obscurity with URLConnection. But not in this thread.