Wait, is this the fix to that annoying thing when you copy a large file to a slow USB/SDCard and the OS instantly reports the copy as being complete, but actually it's just been written to RAM and is slowly being written to the actual media in the background, and if you "safely remove" the device you just have a broken incomplete file? Is this the fix for that, finally!?

Edit: YES, YES IT IS! HOLY SHIT, AMAZING!

[–] Hiro8811@lemmy.world 17 points 3 days ago (1 children)

The safely remove actually forces the data to be written on the disk.

[–] Shayeta@feddit.org 5 points 3 days ago (1 children)

Hmm, that might mean I have another issue as well. Since safely remove would just remove the device instantly without waiting...

[–] thingsiplay@lemmy.ml 6 points 3 days ago* (last edited 3 days ago)

For me, sometimes with huge files even if the copy process ended, and I do a "safely remove", sometimes I still have to wait a big chunk of time. Safely remove is actually safe, nothing should be left. I also thought this was a feature of the filesystem, where it caches and optimizes the actions before doing it under the hood.

With something like System Monitor you should be able to see if anything is writing or reading on the filesystem constantly, before you do a disk remove.

[–] ulterno@programming.dev 5 points 3 days ago (3 children)

I have hated "Safely Remove" from back when I was on Windows.
Always did weird GUI stuff and does on this too.

So I just use syncand when it properly finishes, I do safely remove.

[–] bjoern_tantau@swg-empire.de 4 points 2 days ago (1 children)

I always assumed "safely remove" is just a umount which in turn does the sync before returning.

[–] ulterno@programming.dev 1 points 18 hours ago

Yes. I do too.
But historically, the way it has indicated "working" in cases it takes more than a second, has been not very reliable.
Specially on Ubuntu + GNOME back when I had to use it in the office.

[–] flameleaf@programming.dev 2 points 2 days ago (1 children)

I type sync, then unmount/eject, then safely remove

Can't be too careful

[–] ulterno@programming.dev 0 points 18 hours ago

unmount/eject, then safely remove

If you still have the safely remove option after running "unmount/eject", I need to know what device you used.

[–] Shayeta@feddit.org 2 points 3 days ago (1 children)

Same, waiting for sync -f to finish would help most of the time.

[–] ulterno@programming.dev 1 points 18 hours ago* (last edited 18 hours ago)

TIL, dd has the option conv=fsync that makes it wait until all writing is finished, before exiting.

So you can just touch /path/to/new/filename and then dd ... of=/path/to/new/filename conv=fsync

Of course, you would have to do this for each file, in case it is multiple

[–] exdor@programming.dev 2 points 3 days ago

I had the same with exFAT I think, maybe that is fixed too lets hope

[–] Zachariah@lemmy.world 45 points 3 days ago

The completion progress and complete notification only reflect copying to the local cache and not when the data is actually written out to the removable storage.

[–] Die4Ever@retrolemmy.com 27 points 3 days ago

I think this is a bigger deal than it sounds like when you consider cut and paste, or just moving files. The writing would've been thought to be done even if the cache is still flushing, so it deletes the source files, but the write can still fail after the source files are deleted. The device could fail, it could be unplugged, you might kick it by accident, or have a power outage.

[–] reader@lemmy.zip 24 points 3 days ago (3 children)

what's next?

they'll allow you to have different wallpapers on different virtual desktops?

[–] neo2478@sh.itjust.works 20 points 3 days ago (1 children)

This technology is impossible! You are a rambling mad man for uttering such nonsense!

[–] reader@lemmy.zip 1 points 3 days ago

just use AI

[–] HelloRoot@lemy.lol 6 points 3 days ago* (last edited 3 days ago)

set up workspaces or whatever they are called instead of virtual desktops. The ability to do independent wallpapers is like 50% of their features

[–] Zier@fedia.io 4 points 3 days ago (1 children)

They will never allow that again.

[–] reader@lemmy.zip 1 points 3 days ago (1 children)

why?

[–] Zier@fedia.io 1 points 23 hours ago

Because we have been asking for it back for 10 years.

[–] ShutUpWesley@piefed.zip 14 points 3 days ago

Fucking finally. Been my biggest gripe for about a decade.

[–] pglpm@lemmy.ca 8 points 3 days ago* (last edited 3 days ago)

Does anyone know if this fix will be backported?

Not sure if this addresses the same problem (please let me know if not), but a fix that I've used for the past couple of years is one suggested in these discussions:

https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f
http://lwn.net/Articles/572911/

essentially changing the values of vm.dirty_background_bytes and vm.dirty_bytes. File transfers with the USB have been smooth and fast, on Plasma/Kwin, with this fix.

And this post explains how to make such changes permanent:

https://unix.stackexchange.com/a/149140/515980

Maybe this is useful for people with older versions of Plasma.

[–] ulterno@programming.dev 4 points 3 days ago

I was just recently talking about this with a colleague, who in the end, just said "Windows is better".
Guess now KDE is better. Or has Windows fixed that problem too? (in that case it was kinda sporadic).