This is the only thing I can’t forgive. I accept that it’s hard to say how long something is going to take. But when that bar reaches 100% something should happen pretty fucking snappish.
Shouldn’t be 5 min, but that’s what you get if the drive don’t have both enough RAM and capacitors to hold a decent write cache to extend it’s lifetime. Then the OS have to either wait for drive to report it’s done, or complete the sync from the file system driver’s cache. Or else you simply deal with it being both slower and dying faster…
I was being hyperbolic, but the OS shouldn’t report the transfer as complete if the drive hasn’t reported it’s done.
The fact that the system is able to tell you the transfer isn’t complete when trying to safely remove the drive means the information exists for the file transfer dialogue to utilize.
A simple “finishing things up,” message in the transfer dialogue is all that’s needed. Especially since unplugging a thumb drive without safely removing it (which tons of people do) while a transfer is still ongoing can corrupt the data on the drive.
The main issue here is that there’s a mismatch between userspace perception of state versus that of the kernel driver, and no standardized way to push that information (unless you make your desktop environment add that info by polling the filesystem driver)
Users definitely don’t want blocking dialogs if the userspace visible state is already updated enough to keep working. And ideally your software would check what kind of drive you’re using and report to you when it’s actually fully done as you close the program, but like I said this isn’t standardize
It’s 100% done, but I need you to keep waiting…
Still 100% done. Keep waiting…
Okay, actually done now.
It’s 100% started.
This is the only thing I can’t forgive. I accept that it’s hard to say how long something is going to take. But when that bar reaches 100% something should happen pretty fucking snappish.
Windows gets around this by sitting at 99% instead. it’s the “I’m not touching you” of file management.
Linux: wait, I’ve copied but not yet synced!
Gotta love waiting 5 minutes to detach your thumb drive because your OS straight up lied to you.
Shouldn’t be 5 min, but that’s what you get if the drive don’t have both enough RAM and capacitors to hold a decent write cache to extend it’s lifetime. Then the OS have to either wait for drive to report it’s done, or complete the sync from the file system driver’s cache. Or else you simply deal with it being both slower and dying faster…
I was being hyperbolic, but the OS shouldn’t report the transfer as complete if the drive hasn’t reported it’s done.
The fact that the system is able to tell you the transfer isn’t complete when trying to safely remove the drive means the information exists for the file transfer dialogue to utilize.
A simple “finishing things up,” message in the transfer dialogue is all that’s needed. Especially since unplugging a thumb drive without safely removing it (which tons of people do) while a transfer is still ongoing can corrupt the data on the drive.
The main issue here is that there’s a mismatch between userspace perception of state versus that of the kernel driver, and no standardized way to push that information (unless you make your desktop environment add that info by polling the filesystem driver)
Users definitely don’t want blocking dialogs if the userspace visible state is already updated enough to keep working. And ideally your software would check what kind of drive you’re using and report to you when it’s actually fully done as you close the program, but like I said this isn’t standardize
Then it is not 100% done, now is it?