Qt fails to copy file on ubuntu.
-
-
If behaviour happens with
system()as well then it is not a Qt/QFile::copy()issue. -
You don't check the return results of
system()&QFile::copy(). -
You have read the
QFile::copy()docs where it says:
Note that if a file with the name newName already exists, copy() returns false (i.e. QFile will not overwrite it).
haven't you?
-
Do you know it's empty via
ls -lor viacat? -
The fact that you say "It's often empty" implies to me it could be a timing issue. How long do you allow to elapse between doing the copy and trying to access the data?
-
I find it hard to believe that
system("cp ...")does not work but doing thecpfrom a shell does.... -
If you really find you have to, have a look at
man syncfor forcing a flush.
@JonB Thank you. I will check it.
-
-
-
If behaviour happens with
system()as well then it is not a Qt/QFile::copy()issue. -
You don't check the return results of
system()&QFile::copy(). -
You have read the
QFile::copy()docs where it says:
Note that if a file with the name newName already exists, copy() returns false (i.e. QFile will not overwrite it).
haven't you?
-
Do you know it's empty via
ls -lor viacat? -
The fact that you say "It's often empty" implies to me it could be a timing issue. How long do you allow to elapse between doing the copy and trying to access the data?
-
I find it hard to believe that
system("cp ...")does not work but doing thecpfrom a shell does.... -
If you really find you have to, have a look at
man syncfor forcing a flush.
@JonB
Thank you very much!I think I have solved the issue by using sync to force a flush.
Maybe you think it hard to believe that system("cp ...") does not work but doing the cp from a shell does....
But it is true. I tested more then ten times for each methods. But I don't know the reason. Could you tell me that, if you know?Thanks again.
-
-
@JonB
Thank you very much!I think I have solved the issue by using sync to force a flush.
Maybe you think it hard to believe that system("cp ...") does not work but doing the cp from a shell does....
But it is true. I tested more then ten times for each methods. But I don't know the reason. Could you tell me that, if you know?Thanks again.
@Qingshui-Kong said in Qt fails to copy file on ubuntu.:
But I don't know the reason. Could you tell me that, if you know?
This is your hint:
@mrjj said in Qt fails to copy file on ubuntu.:You do unmount the USB stick after copy to it?
On Linux you most often run
extXkind of a filesystem, which is a journaling file system. This means that writes, moves and w/e else operations you do, don't happen synchronously (i.e. immediately when you issue it). You can think of the journal as kind of transaction processing. You want that because file operations are usually consisting of many small actual writes to the nonvolatile memory and if something interrupts any of them you don't want your filesystem to be gone for good. This however implies that the journal has to be flushed, and if you don't do it explicitly for many devices it is done implicitly when youumountthem. Since you don'tumountyour USB, the journal is never flushed and no data is in actuality written on the stick.syncdoes exactly that - you explicitly flush the journal, thus even when you don'tumountthe device it does contain the actual data. As an advice: always unmount your devices. -
@Qingshui-Kong said in Qt fails to copy file on ubuntu.:
But I don't know the reason. Could you tell me that, if you know?
This is your hint:
@mrjj said in Qt fails to copy file on ubuntu.:You do unmount the USB stick after copy to it?
On Linux you most often run
extXkind of a filesystem, which is a journaling file system. This means that writes, moves and w/e else operations you do, don't happen synchronously (i.e. immediately when you issue it). You can think of the journal as kind of transaction processing. You want that because file operations are usually consisting of many small actual writes to the nonvolatile memory and if something interrupts any of them you don't want your filesystem to be gone for good. This however implies that the journal has to be flushed, and if you don't do it explicitly for many devices it is done implicitly when youumountthem. Since you don'tumountyour USB, the journal is never flushed and no data is in actuality written on the stick.syncdoes exactly that - you explicitly flush the journal, thus even when you don'tumountthe device it does contain the actual data. As an advice: always unmount your devices.@kshegunov Thank you very much for telling me the details. Now I know the reason why I can solve the issue by using sync.
I can't umount the device, because my application is showing fullscreen. So I can't operate the system. I think I can add a function to my software to umount the device.
But I still wonder why doing the cp from a shell works even though I don't umount the device.
-
@kshegunov Thank you very much for telling me the details. Now I know the reason why I can solve the issue by using sync.
I can't umount the device, because my application is showing fullscreen. So I can't operate the system. I think I can add a function to my software to umount the device.
But I still wonder why doing the cp from a shell works even though I don't umount the device.
Maybe you think it hard to believe that system("cp ...") does not work but doing the cp from a shell does....
But it is true. I tested more then ten times for each methods. But I don't know the reason. Could you tell me that, if you know?But I still wonder why doing the cp from a shell works even though I don't umount the device.
Sorry, but I simply do not believe that sitting in a shell and executing a
cpwill behave any differently than sitting a program and executingsystem("cp ...")! (Assuming same permissions etc.) The shell itself is a program, and when it executes/bin/cpfor you it will be using code not dissimilar (in terms of behaviour) from goingsystem("cp").You still did not put in the necessary error checking, and reading of stderr in case something appears there, when your code goes
system("cp ...")with your arguments. So there is a chance that thecpyou execute from your code is not doing what you think.As for why
cpworks for you at all: there is a chance it executes afsync(2)for you on this particular file, though frankly I would be surprised if it did. -
Maybe you think it hard to believe that system("cp ...") does not work but doing the cp from a shell does....
But it is true. I tested more then ten times for each methods. But I don't know the reason. Could you tell me that, if you know?But I still wonder why doing the cp from a shell works even though I don't umount the device.
Sorry, but I simply do not believe that sitting in a shell and executing a
cpwill behave any differently than sitting a program and executingsystem("cp ...")! (Assuming same permissions etc.) The shell itself is a program, and when it executes/bin/cpfor you it will be using code not dissimilar (in terms of behaviour) from goingsystem("cp").You still did not put in the necessary error checking, and reading of stderr in case something appears there, when your code goes
system("cp ...")with your arguments. So there is a chance that thecpyou execute from your code is not doing what you think.As for why
cpworks for you at all: there is a chance it executes afsync(2)for you on this particular file, though frankly I would be surprised if it did.@JonB One another possibility for different behaviour: different environments in a terminal and when calling cp with system().
-
@JonB One another possibility for different behaviour: different environments in a terminal and when calling cp with system().
@jsulm
Possibly true, but can you name anything in the environment which is going to make a command-line-invokedcpbehave the slightest bit differently wrt syncing to a USB device? Because I can't :) Just in case, perhaps the OP should test running his app from the terminal instead of from Qt Creator if that's what he's currently doing... -
@jsulm
Possibly true, but can you name anything in the environment which is going to make a command-line-invokedcpbehave the slightest bit differently wrt syncing to a USB device? Because I can't :) Just in case, perhaps the OP should test running his app from the terminal instead of from Qt Creator if that's what he's currently doing... -
Hi,
How are you handling the device ?
Are you mounting manually ?
Is your application responsible for that part too ?
Do you have multiple devices and not writing on the same by accident ? -
Hi,
How are you handling the device ?
Are you mounting manually ?
Is your application responsible for that part too ?
Do you have multiple devices and not writing on the same by accident ?@SGaist As I said, I didn't mount or unmount manually.
And I only have one ubuntu system and one USB disk. -
Hello everybody,
Could somebody give me some advis?
I want to copy file to U-storage. But the file on the destination directory is alway empty.
I hope somebody will help me to solve this problem this time.
Thanks in advance.
My enviroment:
Ubuntu 16.04
@jsulm @mrjj @JonB @kshegunov @SGaist
Thank you all!
I think maybe I should learn more knowledge about Linux system. -
@jsulm @mrjj @JonB @kshegunov @SGaist
Thank you all!
I think maybe I should learn more knowledge about Linux system.@Qingshui-Kong
Yes and no! The question you are asking about the behaviour of a mounted USB drive, and seeming to need to either unmount orsync/fsync(), is actually a nasty area! I too would not be sure of behaviour, so it's very understandable that you are unsure :) -
@Qingshui-Kong
Yes and no! The question you are asking about the behaviour of a mounted USB drive, and seeming to need to either unmount orsync/fsync(), is actually a nasty area! I too would not be sure of behaviour, so it's very understandable that you are unsure :) -
@JonB
OK. Thank you! I use sync to solve the problem.@Qingshui-Kong
Yes, that seems OK. It forces the OS to flush the pending content to the USB file, without which your problem seems to occur, so it is understandable.Running
syncon its own asks the OS to flush all file systems, which technically you do not need. If you wish to improve on this, from a terminal runman syncto read its syntax. There you can see that if you specify the individual USB file path as an argument it will only sync/flush that file system, which is all you need. -
@Qingshui-Kong
Yes, that seems OK. It forces the OS to flush the pending content to the USB file, without which your problem seems to occur, so it is understandable.Running
syncon its own asks the OS to flush all file systems, which technically you do not need. If you wish to improve on this, from a terminal runman syncto read its syntax. There you can see that if you specify the individual USB file path as an argument it will only sync/flush that file system, which is all you need.@JonB OK. Thank you very much!
