Copy of large files and QFileSystemWatcher under windows
-
Hi,
When copying large files, I usually avoid letting QFile do that alone. I usually do the read/write operation by hand to allow for better feedback and GUI responsiveness.
-
Hi,
When copying large files, I usually avoid letting QFile do that alone. I usually do the read/write operation by hand to allow for better feedback and GUI responsiveness.
@SGaist What do you mean do the read/write operation by hand?
-
Yes, I use QFile for the read and write part.
-
@SGaist It is not copy by programming.
I have an app made with QFileSystemWatcher(a file synchronization app) that monitors and watches a directory and when I run the app and that I copy a large file into the watched directory, the signal directoryChanged of QFileSystemWtacher is emitted at the beginning of the copy of the large file and it should be at the end of the copy of the large file ...that's my problem -
@SGaist It is not copy by programming.
I have an app made with QFileSystemWatcher(a file synchronization app) that monitors and watches a directory and when I run the app and that I copy a large file into the watched directory, the signal directoryChanged of QFileSystemWtacher is emitted at the beginning of the copy of the large file and it should be at the end of the copy of the large file ...that's my problem@stephane78 said in Copy of large files and QFileSystemWatcher under windows:
it should be at the end of the copy of the large file
Why do you think it should? I know, you need it at the end, but maybe someone else needs it at the beginning.
-
The only two things I can think of are:
- try KDirNotify instead
- Afetr you get the "beginning of copy" signal, store the file size, start a QTimer (500ms?) and check the file size again, if they are equal it probably is finished. I know it's not optimal
-
The only two things I can think of are:
- try KDirNotify instead
- Afetr you get the "beginning of copy" signal, store the file size, start a QTimer (500ms?) and check the file size again, if they are equal it probably is finished. I know it's not optimal
@VRonin Thank you VRonin, but how can I use KDirNotify because I am under windows (the main version of this app must run under windows although there will be perhaps a mac and linux version too) and KDE runs under linux.
for the solution with the timer I will perhaps try it...thanks -
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
