Keep windows trying to read a file

Question

I'm working in a sort of encapsulation of the windows filesystem.

When the user request to open a file, windows calls to my driver to provide the data. In normal operation the driver return the file contents which is cached, However, in some cases the real file is not cached and I need to download it from the network.

The question is if it's possible to keep Windows trying to read the file without blocking the entire drive operation neither the software which open the file, giving the user a chance to cancel the opening process.

At first, i tried to block the driver until data is available, this solution is the more straightforward to implement, but the user experiencie isn't the best. Moreover, relying in network transfer isn't a good idea, the transfer could last for many time and the driver will be block all that time.

The second way I have implemented, consist in return only data when the file is cached and when the file isn't available tell windows that the file is 0 size length, and download the file in a background proccess. With this, the driver don't block windows, and the user experience improve, but the user need to open N times the file until data is available.

I think that the best solution will be to return windows a message like "No data available, try again in 5 secs", i think that if the driver return the apropiate error code to windows this could be achieved, but the error list is too long and the names aren't always as descriptive as you want.

Do you have some advice implementing this? Thanks in advance.

Answer 1

you could spawn a thread that tries again and again, reporting the result on success or timeout.

Answer 2

To me showing a message "No data available, try again in 5 secs" sounds very bad, but it depends on your senario ( You could perhaps elaborate on what your and goal is).

Regarding getting data from the network, this sounds like a prime example of where threading comes into play. Have you considered copying the file in a worker thread? That way you dont have to block anything, and the user does not feel like the system is hanging

Answer 3

The behavior you implement is correct for a driver. The responsibility for handling slow I/O lies at a higher level. For instance, Windows Explorer is very careful in NOT trying to retrieve even a single byte from any file, relying purely on metadata.

However, do not return a failure code when you're busy. It's that failure which would force users to repeatedly open a file.