799
Progress Bars
(sh.itjust.works)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 08 Dec 2025
799 points (100.0% liked)
Comic Strips
20539 readers
3096 users here now
Comic Strips is a community for those who love comic stories.
The rules are simple:
- The post can be a single image, an image gallery, or a link to a specific comic hosted on another site (the author's website, for instance).
- The comic must be a complete story.
- If it is an external link, it must be to a specific story, not to the root of the site.
- You may post comics from others or your own.
- If you are posting a comic of your own, a maximum of one per week is allowed (I know, your comics are great, but this rule helps avoid spam).
- The comic can be in any language, but if it's not in English, OP must include an English translation in the post's 'body' field (note: you don't need to select a specific language when posting a comic).
- Politeness.
- AI-generated comics aren't allowed.
- Adult content is not allowed. This community aims to be fun for people of all ages.
Web of links
- !linuxmemes@lemmy.world: "I use Arch btw"
- !memes@lemmy.world: memes (you don't say!)
founded 2 years ago
MODERATORS
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 standardized