Copy of large files and QFileSystemWatcher under windows

[VRonin]

The KDE API has been rewritten in version 5 to be platform independent. The KIO module (which contains KDirNoitify) runs on all desktop platforms (i.e. not on android) by default

[stephane78]

@VRonin thanks I didn't know it. and I should compile the KIO module or library and link it with my app ? I have looked at the url and it seems it uses QtDbus. Can I use QtDbus under windows too? and the signals that are emitted seem to be for files and not for directories ? or is it for directories too ?
it seems although more powerful that QfileSystemWatcher, because there are only two signals emitted by QfileSystemWatcher directoryChanged and fileChanged, that's why, I have added code in a class to process all the cases...

[stephane78]

@VRonin Hi it is the class KDirWatch that does that (link text (Ihave asked to the developper of KIO)
I will try this class KDirWatch....

[stephane78]

@VRonin, I have watched the code of KDirWatch but I think it doesn't solve my problem, so I will try to use your solution with the timer...;thanks

[stephane78]

@VRonin, I have a question before testing, does QFile::size() return the actual size of the large file being copied (so not complete) or does it return 0 ?

[VRonin]

QFile does not know it's being copied so it will return the actual incomplete file size.

One other thing that comes to mind but I did not test is that the copy probably locks the file for writing so attempting QFile::open(QIODevice::WriteOnly) might return false

[stephane78]

@VRonin OK my problem is solved thanks to you. I have made it with timers.....

[VRonin]

Can you share your final code so other users can benefit from the solution?

[stephane78]

@VRonin not all my code because it is a for a Saas software of my company that will be copyrighted (we use Qt-LGPL)...But I can say something important : the condition to test the end of the copy of the large file (in the slot connected to the timeout ) is the equality of previous size and current size and QFile::open(QIODevice::ReadOnly).In my case I use ReadOnly because I use the file and read it after again to use it and it is ok. and it works.a third condition that I have putted in the test is that the current size is not equal 0 because I believe that QFile::size() return 0 so long the file is not finished copied but I am not sure of this condition but if I remove it, I have a visual c++ runtime error that comes .
so you have the three conditions of the test of the end of the copy of the large file and it is the most important.
the left is specific to my software.
but When I detect a new file added thanks to QFileSYstemWatcher I create a new object with the path of the file and in the constructor of this object I create a timer and start it.so for each file added in the directory there is a new timer that will be deleted later after use of this object linked to the file.....
so there are enough hints now to make the things....

[stephane78]

@VRonin, I have tested it with a 1,85 Gb file because we are limited to 2Gb files....

[VRonin]

on the file size =0 I think it's my fault as the docs clearly state:

if the device is closed, the size returned will not reflect the actual size of the device.

so before QFile::open() ,QFile::size() is meaningless

[stephane78]

@VRonin so my test is not really correct, I have now read that too in the documentation. because my test is :
if (currentsize&&currentsize==oldsize&&f.open(QIODevice::ReadOnly))

//(and currentsize=f.size();)

[stephane78]

@VRonin it is ok with this test but not perfect, I suppose currentsize=0 and f.open returns false so long the copy is not finished

[VRonin]

I would use:

bool check = f.open(QIODevice::ReadOnly);
check = check && currentsize==oldsize
if(check)

[stephane78]

@VRonin I have made several tests with your condition :

bool check = f.open(QIODevice::ReadOnly);
currentsize=f.size();
check = check && currentsize==oldsize
if(check)

and it is ok (for small files and larges files).so thanks I will keep it....