Continue copying when there is e.g. a duplicate

Submitted by majest

Assigned to Jannis Pohlmann

Link to original bug (#11340)

Description

I started copying a few 10s of gigs from one disk to another then went away to let it finish. When I came back it was stopped at about the 3rd file reporting that there was a duplicate file. Unfortnately it didn't continue copying the other files and just waited for me. So then I had to wait all over again for it to copy the files.

Perhaps a nice feature would be for Thunar to copy all the files that it can while waiting for user input.

fuank said:

I second this suggestion. Conflicting files could be added to a queue, other files could be copied asynchronously from the dialog.

However, the dialogue would need to block the interface somehow. Don't want to have unresolved conflicts floating around.

Alexander Schwinn @alexxcons said:

agreed, that would be a nice feature. Patches are welcome !

changed title from Continue copying when there is a duplicate to Continue copying when there is e.g. a duplicate

added 2. Enhancement 5. File Operations labels

mentioned in issue #102 (closed)

This feature would need to modify thunar_transfer_job_copy_file() to call dialog asynchronously. This can be done by not using gtk_dalog_run() and reading "GtkDialog::response" signal directly. As a consequence, thunar_transfer_job_copy_file() needs to return new type of status "waiting for user response". But since the return type is GFile, it would require new return value as a pointer argument. This, in return, would require thunar_transfer_job_copy_node() to delay the current node and keep it elsewhere until the user decides the output. Also, since most of the dialog has "apply to all files" option, a dialog for each error should be unique. This cannot be done by just pushing the file to the end of the list, since that would cause the endless loop of checking each node again and again, just to get the same error until the dialog of the same type of error receives "ok, but only for this file" response and repeating the same merry-go-around with one less file. So, for this reason, it would require separate list for each type of error. The transfer job also has to handle a lot of asynchronous events, since the event loop (signals) and the thread for transfer job is definitely not synchronous. It also has to handle all the dialog (and the related file list) when the job is cancelled.

This solution requires too much complication, but the problem stated on this issue only requires to copy files without being blocked. The alternate solution would be adding a "default response", so a dupicate file can be overwritten, skipped, or renamed. The default would be "ask a user", as it has been a default behavior.

Also, since most of the dialog has "apply to all files" option, a dialog for each error should be unique. This cannot be done by just pushing the file to the end of the list, since that would cause the endless loop of checking each node again and again, just to get the same error until the dialog of the same type of error receives "ok, but only for this file" response and repeating the same merry-go-around with one less file.

Not so clear to me why "just pushing the file to the end of the list" would be a problem here. As soon as a copy operation with a pending dialog is reached, you dont need to loop any more. Just show the dialog and wait until it is answered. Remember the answer in thuner_transfer_job if it is "apply to all".

After that, works on the next copy operation. Show the pending dialog (or skip it if 'thuner_transfer_job' already has a "apply to all files").

It also has to handle all the dialog (and the related file list) when the job is cancelled.

I would rather make thunar_transfer_job_copy_node smarter for that purpose, so that each single copy operation knows its source and destiny, and optionally can manage a dialog.

The alternate solution would be adding a "default response", so a dupicate file can be overwritten, skipped, or renamed. The default would be "ask a user", as it has been a default behavior.

I dont think it is worth to go that way. I suppose typically users dont expect to face problems during a copy process. And if so, they would fix them beforehand. Like that the feature would only help for trouble which anyhow is expected.

As soon as a copy operation with a pending dialog is reached, you dont need to loop any more.

That would be true if the node list keeps not only the source file and the destination, but also the status of that operation. That's just a weird kind of datatype that keeps multiple lists. It would require additional memory per node, and it would be inefficient to handle "apply to all" since the different type of error can be mixed in.

I would rather make thunar_transfer_job_copy_node smarter for that purpose, so that each single copy operation knows its source and destiny, and optionally can manage a dialog.

The problem is that dialog is handled in a different thread (in other words, ThunarTransferJob no longer has a direct control on a dialog). Every dialog signal is tied to the main loop, but the transfer job is on a separate thread.

And if so, they would fix them beforehand.

If so, why do we need this feature at the first place? I don't think I have seen this kind of feature in any popular file manager, after all.

That's just a weird kind of datatype that keeps multiple lists. It would require additional memory per node, and it would be inefficient to handle "apply to all" since the different type of error can be mixed in.

Not clear to me what you mean by 'multiple lists' The status of each single operation could be an enum I suppose, e.g. 'skip/replace/rename/waiting_for_input', "apply to all" would be stored on job-level, not per operation (e.g. 'skip_all/replace_all/rename_all/default'). As soon as the job-level enum is different from 'default', no new dialog would be required for the single operations.

Sure, that would require a small amount of extra-memory per node.

The problem is that dialog is handled in a different thread (in other words, ThunarTransferJob no longer has a direct control on a dialog). Every dialog signal is tied to the main loop, but the transfer job is on a separate thread.

Yes, most likely mutexing would be required for shared resources, used in the dialog callbacks.

If so, why do we need this feature at the first place? I don't think I have seen this kind of feature in any popular file manager, after all.

I was referring to your alternate solution proposal "default response" which only would help for expected problems, where the user knows how to resolve conflicts beforehand.

The original 'continue copy while there is an dialog' idea IMO still is worth to be implemented.

marked #1061 (closed) as a duplicate of this issue

marked this issue as related to #1061 (closed)

mentioned in issue #1266 (closed)

marked #1476 (closed) as a duplicate of this issue

marked this issue as related to #1476 (closed)