> I'd just like to point out that specific issue you linked to happens on Windows too

The poster of the question explicitly states that this behavior does not happen on Windows using the same hardware. And indeed, Windows doesn't cache as aggressively as Linux does (which is one of several reasons why Linux tends to have better disk performance and less risk of disk fragmentation), so no, by design, this issue is more pronounced on Linux.

The actual reason why Windows users are told to explicitly eject instead of just yanking the device is because there are various background processes that might be writing to the device (particularly relevant if you're using SpeedBoost or whatever it's called), not because of file copy progress bars being entirely unaware of the OS' caching mechanisms.

It doesn't happen on Windows because the cache is made to be small enough that the caching and flushing happen at the same time regardless of the size of your RAM. So your transfer progress bar will end at approximately the same time as the actual transfer. I don't use MacOS but I assume they have the UX & UI figured out as well. That's not the case on Linux, the progress bar will disappear in seconds while the transfer can last hours.

And, I say this with no ill-will toward you, I'm not trying to be antagonistic but you're having the same response as all linux users I encounter online. You're denying the problem even exists, saying it's not fair and it might be rough for some use cases? This is transferring a file to a USB stick, this is a very basic use case, and the UI is broken and the UX is dogshit (excuse my french). If we can't admit there is a problem we're never going to get around to fixing it.

It depends on the size of your RAM as far as I understand the issue.