Lmde7 branch#3771
Open
a-j-bauer wants to merge 15 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current situation
(This time I double checked)
I added some debug output to GIO's gfile.c splice_stream_with_progress function to show the current situation.
When a file is copied to a slow block device like a USB thumb drive, the GIO's g_file_copy function
is called with a progress callback function pointer. This has to be called by the GIO's copy / move function to give visual
feedback to a human user. The user expects to see a meaningful dialog that shows how much of the file
is written to the device, a percentage and or remaining time estimate. All of this cannot be done if
the calls are not evenly distributed over the duration time range.
GIO does not have a copy function on it's iface for this in g_file_copy:
so it uses the function file_copy_fallback which in the end uses splice.
The following is the function that GIO uses to write the data if the splice (splice data to/from a pipe)
function is available on the system. From the Linux manual page for splice:
GIO - gfile.c - with debug output:
Copying a 3GB .iso file from a local SSD to a mounted local USB thumb drive
This outputs:
So splice_stream_with_progress reports 100% after 1-2 seconds using splice. The kernel is
doing the rest under the hood which can easily take minutes to complete. For those who want to see or display write progress, this does not work, the kernel's splice / do_splice are not designed to report progress.
The user get's frustrated and removes the thumb drive with data loss, blaming Linux.
GIO - gfile.c
Proposal
Regular files when copied to a mounted consumer device are copied synchronously so that the Desktop user can see progress.
(is_regular_gfile_and_dest_is_consumer_usb_blk_device)
This should effectively solve issues 1644, 3465, 3526, 3677.