QFile::copy only copies file after the GUI is closed?

[bobbayribs]

Hi,

I have a QtConcurrent::run method that copies a pdf file from one directory to the next. This copying is in a separate thread because the pdf files can be quite large and to prevent the main GUI thread from being blocked from doing other tasks.



void MainWindow::CopyPDFsToDestDir()
{
//setup srcFile and destFile
...
QFile::copy(srcFile, destFile);
}

QFuture<void> result = QtConcurrent::run(this, &MainWindow::CopyPDFsToDestDir);


The QtConcurrent::run call is in a loop for x number of files depending on user selections.

It works great on my linux machine (RedHat) and files are copied one by one, but a customer states that on his linux machine (RedHat), the directory only contains 1-2 pdf files. Only after he closes the GUI, suddenly there are 20+ pdf files.

It is as if, the copying of pdf files are being buffered and only flushed upon closing of the GUI. Does this make any sense? :confused:....isn't QFile::copy immediate? or perhaps the QtConcurrent::run threading the cause?

[anda_skoa]

How is the function determining which file to copy?

Is it dequeing filenames from a container? Is that properly protected against concurrent access?

Do you do anything with "result"?

Cheers,
_

[bobbayribs]

How is the function determining which file to copy?

Is it dequeing filenames from a container? Is that properly protected against concurrent access?

Do you do anything with "result"?

Cheers,
_

Oh my!!! I just got off a screen sharing call with the customer. He was viewing the files in Dolphin browser, which wasn't updating the list of pdf files in real time. (Need to hit F5 to refresh).

The files were being created this whole time. Spent so many hours debugging and researching. :crying::crying::crying:

Thank you for the suggestions though.

[d_stranz]

Customers. Can't live with them, can't live without them. It would be great if we could only sell to people who were qualified to use our software, but then we'd starve.