Rename/Move: enable "Move to all selected ..." option

[DrShark]

In Copy dialog, under Option there is a handy one called "Copy to all selected folders/links in target panel".
For Rename/Move dialog, this option is completely disabled.

I guess currently this option is disabled for safety reasons, but I think TC could make it safe enough by either copying each file from source to selected destinations 1 by 1 and ask whether user wants to delete from source if couldn't copy to at least 1 destination location.

If this is too complex for now, I suggest to enable it under a name "Move to selected folder/link in target panel" at least for a case if only 1 folder/link is selected in a target panel - then it will be a good alternative to Shift+Drag&Drop and there will be no need to switch to target panel to enter the destination dir in it before moving with F6 on keyboard.

[Fla$her]

Support++

I don't see any problems in resolving the option.
At the moment, on the "Dialog box: Choose command" page, the option "A: Copy to all selected folders in the target panel" is specified for CM_COPY and CM_RENMOV.

[petermad]

Support+++

[ghisler(Author)]

The problem is that move should only occur when all operations were a success. This cannot be handled with how copy to multi currently works, where a line is added to the background transfer manager for each copied file and each target.

[Fla$her]

2ghisler(Author)
The answer is unclear. Why is it impossible to wait for the copy to be performed in order to delete the selected one at the end?

[ghisler(Author)]

The "Move to all selected ..." option adds one line to the background transfer manager for each file and destination. So if you copy 10 files to 3 destinations, it adds 30 lines. While I could add 3 "delete" commands after these (one for each file), there would be no guarantee that the copy operations would be a success. Alternatively, I could make the first last operation for each file a "move", but this could also have bad effects:
1. If one of the previous copy operations fails, the file will still be deleted by the last operation, which is a move
2. If only the last operation fails, the file will be in the other destinations and would be deleted from the source
3. If the user pauses and rearranges the list, he may be moving a move operation in front of a copy operation of the same file

[Fla$her]

But you can control the progress of the operation. Why not delete only if successful?
If the file cannot be copied to at least one of the folders, it's not deleted. It seems to be not so difficult.

[ghisler(Author)]

The problem is that there isn't just one operation. It's split into multiple separate operations for the files and targets.

[Fla$her]

But you can use a resettable counter and write to the log what was not copied. Is not it so?

[ghisler(Author)]

No, the user could pause the operation and remove some targets where certain files aren't needed.

[Fla$her]

And what's the problem here? If the user wanted to do this, then he should clearly understand that when moving the file in the source folder, it will be deleted.