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?

On Linux you most often run extX kind 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 you umount them. Since you don't umount your USB, the journal is never flushed and no data is in actuality written on the stick. sync does exactly that - you explicitly flush the journal, thus even when you don't umount the device it does contain the actual data. As an advice: always unmount your devices.

Even if we accept, as the basic tenet of true democracy, that one moron is equal to one genius, is it necessary to go a further step and hold that two morons are better than one genius?

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 cp will behave any differently than sitting a program and executing system("cp ...")! (Assuming same permissions etc.) The shell itself is a program, and when it executes /bin/cp for you it will be using code not dissimilar (in terms of behaviour) from going system("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 the cp you execute from your code is not doing what you think.

As for why cp works for you at all: there is a chance it executes a fsync(2) for you on this particular file, though frankly I would be surprised if it did.

@jsulm
Possibly true, but can you name anything in the environment which is going to make a command-line-invoked cp behave 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...

@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 or sync/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, 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 sync on 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 run man sync to 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.