After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695721 - Confirming a move/copy should not block the transfer queue
Confirming a move/copy should not block the transfer queue
Status: RESOLVED DUPLICATE of bug 339420
Product: nautilus
Classification: Core
Component: File and Folder Operations
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 752896 779578 (view as bug list)
Depends on: 770770
Blocks:
 
 
Reported: 2013-03-12 19:24 UTC by Denis Jasselette
Modified: 2018-06-07 23:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Denis Jasselette 2013-03-12 19:24:26 UTC
Hi,

Here is an example of the behavior I am talking about in a trivial case. I move two files A and B at once to another location where a file named A already exists. The transfer of B is queued and waits until the transfer of A is done. In this case, A is a conflict which has to be resolved by the user via a dialog. B is therefore unnecessarily blocked.

The desired behavior IMHO would be:
1. trigger the dialog for A
2. in parallel look through the queue for the next file not in conflict: B and process it (putting it at the front of the queue)
3. once B is done, check on the status of the next file in the queue: A. If the conflict is resolved proceed normally, otherwise, go back to 2.

I can't really think of a case where changing the ordering of the queue would be bad. No time would be wasted waiting for the user's response. Especially for long transfers where the user is AFK.
Comment 1 António Fernandes 2017-08-21 16:53:17 UTC
*** Bug 752896 has been marked as a duplicate of this bug. ***
Comment 2 António Fernandes 2017-08-21 16:53:22 UTC
*** Bug 779578 has been marked as a duplicate of this bug. ***
Comment 3 António Fernandes 2018-06-07 23:56:12 UTC

*** This bug has been marked as a duplicate of bug 339420 ***