GNOME Bugzilla – Bug 774460
No progressbar while importing files from camera
Last modified: 2016-12-10 00:09:17 UTC
Created attachment 339904 [details] screenshot After upgrading from 3.20 to 3.22 I noticed that nautilus not showing progress of import media from my Canon SX50. No progress, only n/0 files, no Mb/s speed. Downgrading from gvfs/gvfs-gphoto 1.30 to 1.28 not resolving a proplem.
I've seen a similar problem when copying from an iphone, I believe it's related to bug #766027 and https://git.gnome.org/browse/nautilus/commit/?id=24dae9e This expects G_FILE_ATTRIBUTE_ID_FILE to be available, and won't get number of files/bytes to copy if it's not there. The problem is that no gvfs backends seem to provide it (unless there is a fallback somewhere, I only git grep'ed for it in gvfs git repository).
Created attachment 340673 [details] [review] file-operations: Fix progress of copies over gvfs commit 24dae9e0a "file-operations: avoid scanning the same files" added a way to skip files which have already been processed in scan_dir(). To do that, the code uses G_FILE_ATTRIBUTE_ID_FILE, which does not seem to be widely implemented by gvfs modules. When the file has no ID, it will not be accounted for in the SourceInfo structure used to track copy progress, resulting in progress not being shown, and Nautilus saying that it's copying 0 files. This commit changes the logic to use the file URI instead of the file ID to check if the file has already been processed.
Created attachment 340674 [details] [review] file-operations: Fix progress of copies over gvfs commit 24dae9e0a "file-operations: avoid scanning the same files" added a way to skip files which have already been processed in scan_dir(). To do that, the code uses G_FILE_ATTRIBUTE_ID_FILE, which does not seem to be widely implemented by gvfs modules. When the file has no ID, it will not be accounted for in the SourceInfo structure used to track copy progress, resulting in progress not being shown, and Nautilus saying that it's copying 0 files. This commit changes the logic to process the file if it has no ID, or if its ID hasn't been seen yet. An alternative would be to g_file_get_uri() rather than G_FILE_ATTRIBUTE_ID_FILE to detect already processed files.
Either of these patches fixes the issue for me.
Builded with patch over 3.22 branch and issue is fixed for me too. Tested with MTP/PTP.
Created attachment 340889 [details] [review] file-operations: Fix progress of copies over gvfs commit 24dae9e0a "file-operations: avoid scanning the same files" added a way to skip files which have already been processed in scan_dir(). To do that, the code uses G_FILE_ATTRIBUTE_ID_FILE, which does not seem to be widely implemented by gvfs modules. When the file has no ID, it will not be accounted for in the SourceInfo structure used to track copy progress, resulting in progress not being shown, and Nautilus saying that it's copying 0 files. This commit changes the logic to use the file URI instead of the file ID to check if the file has already been processed.
(In reply to Christophe Fergeau from comment #6) > Created attachment 340889 [details] [review] [review] > file-operations: Fix progress of copies over gvfs Only change from the previous iteration is the use of GAuto*. I haven't been able to test it yet though because of some gvfs/nautilus issues on my machine making it unable to detect my iPhone :)
Review of attachment 340889 [details] [review]: Thanks for the patch! there is a small nitpick I will fix in a upcoming patch (so I can commit already and do a release with your patch in it :) ) ::: src/nautilus-file-operations.c @@ +3178,3 @@ + file = g_file_enumerator_get_child (enumerator, info); + file_uri = g_file_get_uri (file); + g_warn_if_fail (file_uri != NULL); this cannot happen, so the warn is not needed. @@ +3341,2 @@ + file_uri = g_file_get_uri (file); + g_warn_if_fail (file_uri != NULL); ditto