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
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