[Qt-interest] QNetworkDiskCache broken in 4.5

[Marcus Williams]

Hi -

I'm trying to use the QNetworkDiskCache in qt 4.5 but it doesnt work as 
expected. I've narrowed this down to a couple of reasons. The first is 
that the Cache doesnt work at all initially under windows because it 
creates a temporary file (its "prepared" file) for the contents of the 
cached file which it then tries to move to the cache directory using the 
QTemporaryFile::rename - I suspect this fails because the file is open.

---- From QNetworkDiskCache.cpp around line 249 ---
     if (cacheItem->file
         && cacheItem->file->isOpen()
         && cacheItem->file->error() == QFile::NoError) {
         cacheItem->file->setAutoRemove(false);
         // ### use atomic rename rather then remove & rename
         if (cacheItem->file->rename(fileName))
             currentCacheSize += cacheItem->file->size();
         else
             cacheItem->file->setAutoRemove(true);
----------------------------------------------------

If I "fix" this by changing the rename call to a copy call and then 
closing the file (to fix a bug that leaves open file handles around), 
this gets the file into the cache correctly.

If I then construct a network request to the same url the cache is hit 
correctly and the data is fed into the reply from the cache. The bug I'm 
hitting is that the finished() signal never gets emitted so my code just 
sits there waiting for the file contents.

Looking at the non-cached code route it appears that the finished signal 
is called explicitly in 
QNetworkAccessHttpBackend::downstreamReadyWrite(), but this doesnt 
happen in the cached version as the cache contents is sent within 
QNetworkAccessHttpBackend::replyHeaderChanged() which then returns.

QHttpNetworkConnectionPrivate::allDone queues up a finished signal but I 
never see it so I'm wondering if its a threading issue (my download 
manager works in a separate thread) - all other (non-cached) download 
finished signals are working as expected, so I'm thinking its something 
to do with the way it emits it via invokemethod, rather than signalling 
via emit.

Anyone got any ideas?

Thanks

Marcus