I believe simultanious file transfers are nice but when using it on slower Devices like Tablets and low end Notebooks(I3) It seems limited. When managinng files larger than 2GB having many simultanious file transfers slows down individuel file transfers and puts the CPU under significant load which also causes a significant performance decrease under other tasks untill the file transfers are complete and with 10+ file transfers of 2GB+ that could easily be 20-30 minutes depending on the CPU and HDD. I'm sure this might not be so noticable on fast CPU's with SSD's but i don't have such options. i Imagine most won't I therefore like to request an option in preference to change thunars default behavior between "Queued File Transfer" and "Simultanious File Transfer" preferbly with a setting to decide how many simultanious file transfers are allowed at any given time.
I'm willing to offer a bounty for this feature
Created attachment 6721 Simultaneous or queued copies with preferences In this patch, I added the possibility to queue some copy jobs to other running copy jobs. I added three preferences. By default the behavior is unchanged. I'm not used to write c using Glib framework some please, indicate me if something is not right. Some coding standard might not be right too, even if I tried to mimic other C source files.
One can also find the copy-improved branch in my git repo : http://git.enialis.net/gitweb/?p=thunar.git;a=log;h=refs/heads/copy-improved
Hi yeah that's also a feature I was always missing.. Cyrille Pontvieux how does your patch work, can you cancel individual jobs in the queue? And did you preserve simultaneous copies when their destination is on different file systems? (see "mount" or "df" command) Thanks Simon
Hi! Unfortunately one cannot cancel a job in the queue because I didn't code an UI to view the queue, pause the transfer and of course cancel a job copy. But multiple copy is working like that: - if a current copy job is in progress and either the source or the destination (in filesystem consideration) is the same as the new copy job, the new one is added to the current one. - otherwise a parallel copy is made as usual. The first case is subject to preferences (about the source and the destination checks). By default, both are deactivated, so if you apply my patch without changing preferences, you will not notice a difference. This patch have not been accepted upstream because Thunar development is frozen until gtk3 port is done, which I'm currently doing (still facing two bugs, one crash and one bad ui rendering). But if you don't want to wait, just grab the code from my repo.
I have the same problem (slow devices like usb key, ... ) I also wish to see this feature in Thunar. Nautilus users have the same request : https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/306630 Thanks.
Very nice to have a way to serialize copy on slow device the whole elapsed time will be shorter than concurrent access.
*** Bug 13465 has been marked as a duplicate of this bug. ***
*** Bug 5858 has been marked as a duplicate of this bug. ***
@Cyrille Pontvieux ah oh these source and destination checks sound sensible, did you also consider that when two jobs are already running and a new job is added which matches the destination of the first but the source of the second, then it has to depend on both jobs, eg. with four different filesystems A, B, C, D: 1. cp A/ B/ 2. cp C/ D/ 3. cp B/ C/ In that case Job 3 depends on both job 1 and job 2, I think the best way to implement that UI-wise would be to have numbers before the individual jobs and then write inside a job a message like "Queued, waiting for transfer operation 1 and 2 to finish.."
*** Bug 10809 has been marked as a duplicate of this bug. ***
+1, I'd love to see this feature added.
+1, this feature would be great for transferring files from and to network shares as well.
+1, this feature would be nice to have.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/116. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev