The file transfer progress bar in Dolphin reaches 100% before the data is actually written to the destination disk. Even after the UI reports that the transfer is complete, disk activity continues in the background for a noticeable amount of time.
The expected behavior should be that the progress bar reflects the actual completion of the write operation to the destination device. Alternatively, the UI should clearly distinguish between data that has been buffered (in RAM) or data that has been fully flushed to disk, so users understand the real state of the transfer.
Currently, the behavior is misleading because the progress bar quickly reaches 100% and indicates completion, while in reality the system is still writing data. This creates a poor user experience and can potentially lead to data loss if a user removes an external device assuming the operation has fully finished.
This issue appears to stem from buffered or asynchronous I/O in KIO, where progress reflects data being queued or cached rather than physically written to disk. While this may be an implementation detail, it should not be exposed in a way that misrepresents completion to the user.
A possible improvement would be to report actual disk write progress, introduce a second phase such as “flushing to disk,” or explicitly indicate buffered versus committed progress. This would make the behavior more transparent and align better with user expectations.
This is much more likely the write buffer of the file system, you would get the same with command line tools like cp
From the point of the application the data has been written, hence the progress showing the operation as completed. When cp it will exit, its job done.
This is how the kernel handles file system writes.
It will flush data when needed, e.g. when unmounting or when the buffer memory is needed for something else.
The file can be read, moved, etc. with all data intact as the kernel will know which blocks are where.
But from a user perspective the progress bar is misleading.
Reporting completion when data is only queued (not durably written) creates a false sense of safety — especially for removable media.
There’s a difference between:
“write accepted by kernel”
“write persisted to storage”
The UI currently reflects the first, but users reasonably expect the second.
and i feel if we want linux to be more comfortable and intuitive for everyday users, the UI should reflect what users actually care about — not just internal kernel semantics.
its similar to how browsers handle downloads : if download is still in progress and you try to close the window, it warns you instead of silently allowing a potentially unsafe action.
Even though the system can continue or recover, the UI still communicates the risk clearly.
so i think if data is not yet fully written to the device, users should be informed before they take actions like unplugging or assuming completion.
Once the copy is complete you can use the copy of the file.
Knowing its contents are on disk is not that interesting.
All buffers get flushed to disk in a reasonable time.
If you shutdown the system all buffers pending will be flushed.
If you eject a remvable device all buffers will be flushed before the the user is told it is safe to remove the device.
You’re right that the system eventually flushes buffers and that safe removal handles this correctly.
But that’s not the situation being discussed — the issue is what the UI communicates at the momnt it reports “complete.”
Saying “you can use the file” is not the same as “the data is written,” especially for external media where users often act immediately after completion.
The fact that safeguards exist (like safe eject) actually reinforces the point :- the system does distinguish between buffered and fully written data, the UI just doesn’t surface that distinction during the copy process.
This isn’t about correctness of the kernel behavior, it’s about aligning the UI with real-world user expectations and reducing avoidable data loss scenarios.
I’m raising it here because I use KDE apps daily and care about improving them — not to single out Dolphin or criticize for the sake of it.
I really like the KDE ecosystem, and that’s why i’m discussing this. Small UX details like this can make a big difference in how reliable and intuitive things feel, especially for everyday users.
This just happens to be where I noticed it most clearly.
It reports correctly that the copy/download has been completed.
Especially with a removable media this is even better because unmounting it (safely remove) will ensure all data and metadata like file system changes have been written.
This action has its own progress indication.
This is still the case.
The Dolphin window can be closed because it has handed off the file operation to a background process. This is also the one showing the progress and it will do so until it has completed its task.
There are even browser which do this in a similar way: they close the window but will continue downloading until they are done.
And they also consider the download done when they have written all bytes, not when the OS has written all its buffers to disk.
what about the extremely common scenario of just yanking the thumb drive our of the USB port as soon as the progress bar completes.
who hasn’t done this? and if you haven’t been burned by it, you’ve just been lucky, is all.
i’m with OP, there should be some visual indication on the desktop that unfinished writes are till taking place in the background.
it doesn’t necessarily have to be in the progress bar but a glowing thumb drive icon in the system tray or having a count down timer on it like a notification would be a welcome UX.
Every OS I’ve worked with in the past 10 years has a “Safely remove” type of action to avoid corruption of data or file system when an external drive is removed.
Because the alternative is that every single program is made aware that it is writing to a removable volume and triggers flush after close.
If a system really needs every write to be flushed then it can be configured for that.
The configuration we are currently dealing with as the default was chosen because it has the behavior of what most users expect.
When they hit CTRL+S then want to continue to work as fast as possible, regardless of where the file is stored. The OS supports that by buffering.
Not sure the kernel provides an interface to know that.
Might also depend on the file system.
That would definitely be more useful than blocking UI until completion of every write/modify operation. Would require such state to be available from the kernel.
A sort of reminder that you have to go through “safely remove” if you value your data