Nine minutes to copy a 2.2 gigabyte file tracks to about 4MB/s which wouldn't surprise me for a cheap USB memory stick or using a slowish USB port or copying from a fragmented file from a spinning-metal drive.
My wild guess is that the copy operation is the usual "read a megabyte from source, write a megabyte to destination, over and over again; once that is finished, issue an fsync() on the destination". Probably the progress bar is updated in the loop. That tracks the read speed of the source, not the write speed of the destination. iotop or biotop could probably show if the writes are on-going or not. A "fix" would be to add fsync() calls within the loop. Whether or not that's feasible depends on much more gnome IO knowledge than I've got. Whether or not that would have other horrible consequences would also need to be investigated. (If the source and destination are slow, it might increase the total operation time uncomfortably.) There might be better fixes if a process can learn from the OS how much of the file is actually on the storage medium -- I don't know off-hand a way to do this, but that doesn't mean it doesn't exist. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1871869 Title: Nautilus copy task status is not accurate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1871869/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
