Copy of large files and QFileSystemWatcher under windows
-
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
@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... -
@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... -
@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
-
@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
@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 ?
-
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 -
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@VRonin OK my problem is solved thanks to you. I have made it with timers.....
-
@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.... -
@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....@VRonin, I have tested it with a 1,85 Gb file because we are limited to 2Gb files....
-
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@VRonin so my test is not really correct, I have now read that too in the documentation. because my test is :
if (currentsize&¤tsize==oldsize&&f.open(QIODevice::ReadOnly))//(and currentsize=f.size();)
-
@VRonin so my test is not really correct, I have now read that too in the documentation. because my test is :
if (currentsize&¤tsize==oldsize&&f.open(QIODevice::ReadOnly))//(and currentsize=f.size();)
@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
-
I would use:
bool check = f.open(QIODevice::ReadOnly); check = check && currentsize==oldsize if(check)@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....
