it’s not about KDE’s file transfer progress being flawed but more about how file transfering works at the level of the OS. Almost all modern OSs caches the data sent to drives to RAM instead of actually writing them right away for performance reasons.
But this means that when you have to ensure that data is actually written to the drive ( eg - when removing it from the system ), you have to make sure that the cache is properly ‘flushed’ to the drive. Only problem is, you can’t actually determine the actually time it would take to sync all that cached data.
Even Windows uses the same system. Right up to Windows 8 ( at least ), they would show a message saying something along the lines of ‘removing drive, wait till this operation is over before unpluging’ in a notification when it’s ejected. But users are typically stubborn and disconnects devices before they are properly synced, so they disabled caching for removable drives ( at the cost of some performance ).
The problem KDE is having is actually created by two separate reasons:
-
Their text tells the user exactly what’s happening (“Files are still being transferred”) which ironically confuses the user who doesn’t actually understand it’s inner workings. Windows’ generic “Removing Drive” message makes the user think its taking time to finalize some unknown removal procedure, so they doesn’t question that much.
-
They still use caching for removable devices. This is still the recommended configuration from kernel developers and KDE Plasma doesn’t currently artificially disable caching for them.
BTW, the reason for the progress meter is indeterminate progress bar ( one that only shows some progress is made. not how much ) is that it’s impossible to tell how much time or progress is being made when it comes to writing the cache to the drive.