nautilus should copy/move smarter (queue files)

Bug #306630 reported by Piet Vanraad
158
This bug affects 32 people
Affects Status Importance Assigned to Milestone
Nautilus
Confirmed
Wishlist
One Hundred Papercuts
Invalid
Undecided
Unassigned
gvfs
Invalid
Undecided
Unassigned
nautilus (Ubuntu)
Triaged
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

Say I have a couple of big files to copy. Nautilus should copy them in sequence in stead of in parallel when this is faster. This is often the case. I give an example:

Say I insert an usb stick. I start to copy pictures from the last holiday with some friends. While the copy is going one, I realize that I better also copy the new-years day party of last year, as the same friends where there too. So I drag and drop those to the usb stick. Now I will have to wait a lot longer than if I first copy the first batch and then wait and then copy the second batch. It is just not they way I want to work, but I expect the computer to do it this way.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/nautilus
Package: nautilus 1:2.24.1-0ubuntu1
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=nl_BE.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux 2.6.27-9-generic i686

Tags: apport-bug
Revision history for this message
Piet Vanraad (piet-vanraad) wrote :
Revision history for this message
Pedro Villavicencio (pedro) wrote :

nautilus uses gvfs as a backend, re assigning.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

could you send it upstream at bugzilla.gnome.org since you're interested on the feature? otherwise this bug can be closed if there's no action on it for a few weeks thanks.

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
Revision history for this message
Piet Vanraad (piet-vanraad) wrote :

Before entering, I did a search. Here is the same problem:

http://bugzilla.gnome.org/show_bug.cgi?id=413748

I truly hope this gets fixed!

Revision history for this message
Pedro Villavicencio (pedro) wrote :

thanks, linking the report.

Changed in gvfs:
status: New → Triaged
Changed in gvfs:
status: Unknown → New
affects: gvfs (Ubuntu) → nautilus (Ubuntu)
Revision history for this message
Sebastien Bacher (seb128) wrote :

The user basically suggest that copying you small text file which takes 5 seconds will be blocked for an hour if you copy a DVD image, that seems to not be a so trivial binary choice and probably not an hundredpapercut either

Revision history for this message
Wouter Stomp (wouterstomp-deactivatedaccount) wrote :

No he only says that if both are being copied simultaneously (to the same volume/device), the total time needed is much more than when they copied after each other. Seems pretty trivial to wait for one file to finish copying before starting the next.

Revision history for this message
Sebastien Bacher (seb128) wrote :

So you wait on a DVD to be copied to copy a small image file next, or you need to start having logic on what is copied etc and that's far from being trivial

Revision history for this message
Wouter Stomp (wouterstomp-deactivatedaccount) wrote :

Yes, you wait. But you wait shorter in total than when they are copied simultaneously, like happens now. And the usual case would be like described in the original report: dragging a collection of photos somewhere, and the some more photos and suddenly the copying becomes really slow. In this case it saves lots of time.

Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote :

Intelligent file copy optimization is a feature, not a trivial usability fix; this is a great idea, but not a paper cut.

Changed in hundredpapercuts:
status: New → Invalid
Revision history for this message
Benjamin Radke (jimbanne) wrote :

For me it would be enough to have a pause-Button for every item in the copy dialog. Then I could decide on my own which batch I want to prefer.

Przemek K. (azrael)
summary: - nautilus should copy smarter
+ nautilus should copy smarter (queue files)
summary: - nautilus should copy smarter (queue files)
+ nautilus should copy/move smarter (queue files)
Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

Reassigning to match the product of the upstream bug.

Changed in gvfs:
importance: Unknown → Undecided
status: New → Invalid
Revision history for this message
Walter_I (walter-i) wrote :

Hello, I would like to add 2 cents to this thread:
1) The remark made by "David Siegel" is incorrect.
The request is *not* to implement: <<Intelligent file copy optimization>>, but simply to queue the files to copy so that they're copied sequentially.
If I select 2 files and drag them across two "locations", these two files will be copied sequentially.
If I drag the two files one after the other, the copy will occur concurrently - as a result, the time that it takes to copy the two files will be significantly longer. This should be changed so that the files are copied sequentially even in this case.

2) The behavior of Nautilus is the same as Windows Explorer. There are several tools in Windows (e.g.: TotalCommander) which implement this auto queuing. I mention this because this proves that the implementation is certainly possible.

Revision history for this message
Holger Berndt (berndth) wrote :

@Walter_I
In my oppinion, David Siegel's remark is absolutely correct, and you are wrong. It's not as simple as you put it. Whether or not copying in parallel takes significantly longer depends on a number of factors (is target and/or source on a slow network connection, am I copying from a CD or a SSD etc). Also, sometimes I want parallel copies even if they might be slower in total, to increase reactivity.

Consider the following (exaggerated) use case: I am copying a DVD image to a remote host on a slow link. ETA: 17 hours. Now, 5 hours after I initiated the file transfer, I want to copy a 12 kB ini file from /etc/ to /srv/foo. In your proposed solution, I would have to wait 12 hours for it to arrive. You can't seriously think that this would be an improvement.

I fully agree that Nautilus could be smarter during file transfer management, with a smarter queuing and priority management logic. David didn't claim that it was impossible (and neither do I), but it's not trivial to implement, and certainly not a paper cut.

Revision history for this message
Darshaka Pathirana (dpat) wrote : Re: [Bug 306630] Re: nautilus should copy/move smarter (queue files)

On 05/13/2010 01:56 PM, Holger Berndt wrote:
> @Walter_I
> In my oppinion, David Siegel's remark is absolutely correct, and you
> are wrong. It's not as simple as you put it. Whether or not copying
> in parallel takes significantly longer depends on a number of
> factors (is target and/or source on a slow network connection, am I
> copying from a CD or a SSD etc). Also, sometimes I want parallel
> copies even if they might be slower in total, to increase
> reactivity.
>
> Consider the following (exaggerated) use case: I am copying a DVD image
> to a remote host on a slow link. ETA: 17 hours. Now, 5 hours after I
> initiated the file transfer, I want to copy a 12 kB ini file from /etc/
> to /srv/foo. In your proposed solution, I would have to wait 12 hours
> for it to arrive. You can't seriously think that this would be an
> improvement.

My full ACK goes to Walter: so the possible solution would be to let
the user choose wheter he wants to queue or not. I definitely do *not*
expect some kind of "intelligent" copy process... (at least not in the
first stage of improving the copy/move process).

JM2C && Regards,
 - Darsha

Revision history for this message
Holger Berndt (berndth) wrote :

@Darshaka Pathirana:
How can you "full ACK" a statement that you oppose in your very next sentence? Walter proposed to ALWAYS queue files, which is definitely not a good idea. "Do something more than just always process in parallel or always queue", be it to ask the user, have some smart logic or a mixture of the two, is what I wrote about, and is in any case not a trivial change.

Revision history for this message
Darshaka Pathirana (dpat) wrote :

On 05/13/2010 02:58 PM, Holger Berndt wrote:
> @Darshaka Pathirana:
> How can you "full ACK" a statement that you oppose in your very next
> sentence? Walter proposed to ALWAYS queue files, which is definitely
> not a good idea. "Do something more than just always process in
> parallel or always queue", be it to ask the user, have some smart
> logic or a mixture of the two, is what I wrote about, and is in any
> case not a trivial change.

Ok, sorry. Full ACK went to the statement "The request is *not* to
implement: <<Intelligent file copy optimization>>"..

I did'n state that the change to a queueing behavoir would be trivial.
But I fully agree with the fact that there are some pieces of software
which implement the needed feature... e.g. TotalCommand let's you
choose wheter the file should be copied immediately or be queued.

So again: we (at least me and Walter) don't need the "intelligence" on
software side instead just let the user choose (e.g a seperate "add to
copy-queue" option).

Regards,
 - Darsha

Revision history for this message
JPM (jpm) wrote :

/me wants a port of TeraCopy in Ubuntu.

I will settle with a pause function in Nautilus copy too. Then at least I can queue the copy's myself.

Changed in nautilus:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
Volodymyr Paprotski (paprots) wrote :

It does not have to be complicated actually. I think a workable rule is to queue local files and parallel queue any network file systems. The decision should really come from the gvfs-backends daemon on case by case basis.

Well actually, I have no idea how hard that is to implement, so maybe it is indeed hard.

GIO/Gvfs/Glib library (take your pick) could provide the interface to queue files that the gvfs-backends daemon instantiates and configures. Alexander Larsson might know the best design, as he seems to have written most of the gvfs anyways.

Revision history for this message
Gustavo Acuña (gustavo-ziosoluciones) wrote :

my 2 cents, what about this?

Every copy operation initiated (after the first one) starts in a paused state (its queued), so you see the list of copying operations (or pending ones), but you put a play/pause button next to each operation, so in the standard case everything gets queued, but you press play in the file(s) that you want to want to do concurrently and its done.

Theres no checking for destination, size or any other "intelligent" feature, just autoqueue with the possibility to force parallel copying/moving at the users discretion.

i think we wont have neither of the 2 problems on this case, later it would be cool to arrange the order inside the queue but its out of this scope i guess.

Changed in nautilus:
status: New → Unknown
Revision history for this message
Omer Akram (om26er) wrote :

upstream bug marked as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=124783

Changed in nautilus:
importance: Medium → Unknown
Changed in nautilus:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Revision history for this message
Sylvain Viart (sylvain-viart) wrote :

Same demand on XFCE with Thunar : https://bugzilla.xfce.org/show_bug.cgi?id=12123

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.