803
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
803 points (100.0% liked)
Comic Strips
20549 readers
3974 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
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!
Then it is not 100% done, now is it?
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 standardized