Nautilus copy task status is not accurate.

[John]

Problem is discussed at https://ubuntuforums.org/showthread.php?t=2440314 When copying a large file, using Files (1.34.1-stable), to an external USB thumb drive, the copy progress status will typically say 100% complete and 0" seconds" while the file is still being written to the USB thumb drive (with some thumb drives a user can see the activity light flashing until completion). The amount of time that Nautilus sits there at 100% with 0 seconds left is truly remarkable. It must by 95% of the entire copy task time. To the novice user the "100% and "0 seconds left" status message leaves the expectation that the thumb drive can be removed at any time (novice users will probably just yank the thumb drive out and later on complain about corrupted files). I think this a serious usability issue. This should be changed/fixed.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: nautilus 1:3.34.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-46.38-generic 5.3.18
Uname: Linux 5.3.0-46-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu8.8
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Apr 9 11:15:05 2020
GsettingsChanges:
 b'org.gnome.nautilus.window-state' b'sidebar-width' b'261'
 b'org.gnome.nautilus.window-state' b'initial-size' b'(949, 742)'
 b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'"
 b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'owner', 'group', 'permissions', 'where', 'date_modified', 'date_modified_with_time', 'date_accessed', 'recency', 'starred', 'detailed_type']"
InstallationDate: Installed on 2019-12-27 (103 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)
usr_lib_nautilus:

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[sudodus (nio-wiklund)]

Your observation is correct and I have seen it too. RAM is bigger and processes are buffering in RAM more aggressively in recent computers with recent versions of linux operating systems. Be aware that also Windows uses this feature and for that reason you must 'remove the USB drive safely' or your data on it might get corrupted also in Windows.

For this reason I check flushing the buffers in the new tool to create USB boot drives, mkusb-plug. If you install mkusb-plug, it will bring the shellscript watch-flush, that you can use as a stand-alone program, or use it via the zenity GUI as I use it in mkusb-plug.

It would certainly be possible to do something similar also in Files alias nautilus.

There are pros and cons to let nautilus wait while the buffers are flushed when writing to removable drives, but I agree with your point:

Newbies might be tricked into yanking a USB pendrive before the buffers are flushed. Also more experienced users might forget about unmounting/ejecting. So if nautilus (or maybe a dedicated system service) will show on the desktop that there are still buffered data (alias 'dirty' data) waiting to be written to a removable drive, many users will avoid problems with corrupted files and file systems.

[John (jgwaclawsky)]

Many Thanks for your assistance.

Best Regards

John

On 4/9/20 12:33 PM, sudodus wrote:
> Your observation is correct and I have seen it too. RAM is bigger and
> processes are buffering in RAM more aggressively in recent computers
> with recent versions of linux operating systems. Be aware that also
> Windows uses this feature and for that reason you must 'remove the USB
> drive safely' or your data on it might get corrupted also in Windows.
>
> For this reason I check flushing the buffers in the new tool to create
> USB boot drives, mkusb-plug. If you install mkusb-plug, it will bring
> the shellscript watch-flush, that you can use as a stand-alone program,
> or use it via the zenity GUI as I use it in mkusb-plug.
>
> It would certainly be possible to do something similar also in Files
> alias nautilus.
>
> There are pros and cons to let nautilus wait while the buffers are
> flushed when writing to removable drives, but I agree with your point:
>
> Newbies might be tricked into yanking a USB pendrive before the buffers
> are flushed. Also more experienced users might forget about
> unmounting/ejecting. So if nautilus (or maybe a dedicated system
> service) will show on the desktop that there are still buffered data
> (alias 'dirty' data) waiting to be written to a removable drive, many
> users will avoid problems with corrupted files and file systems.
>

[EAB (adair-boder)]

Ubuntu 20.04 here.
I found reports of the file manager data transfer progress information being unreliable dating back 15 years (https://alt.os.linux.ubuntu.narkive.com/RxvTnprS/still-no-progress-bar-when-copying-files-to-flash-drive) and I cannot understand why, for the love of god, this is still the way it is today!
At the very least the user should be presented with progress information when attempting to cleanly eject the USB stick!

In Windows and MacOS the data transfer progress is actually what one expects - a reality-based depiction of the data being transferred - which when it says it's completed, is actually completed.

In Ubuntu (all Linux?) you get this data transfer progress information which is more of a lie than the truth. And this in a PC OS which is supposed to be intuitive for the average PC user ... or else why bother with most of the GUI if to see something as rudimentary as this you have to start executing terminal commands!?