Your opinion about the Background Transfer Manager

[white]

I think the Background Transfer Manager (BTM) needs discussion badly. My concerns are about the copyflags lines and about the way options in the copy dialog are interpreted.

I think the copyflags lines are not clear to users. They should be clear, because they are very important and dangerous lines. I say dangerous because they can make that your files are overwritten without warning, or moved without verify. You can easily accidently move copyflags lines with serious consequences. Also, you might remove some lines leaving dangerous copyflags lines.

Another thing to consider is when you open the BTM with menu option Commands/Background Transfer Manager and leave this window open. Suppose you copy some folders using F5(Copy), F2(Queue) and you choose to Overwrite all when prompted before overwriting files. When the operation finishes, the BTM remains open. If you don't close the BTM and hours later you copy some other folders using F5(Copy), F2(Queue), files will be overwritten without warning. In TC 8.50b6 this will even be the case when the copy dialog says that files will not be overwritten without warning (see http://ghisler.ch/board/viewtopic.php?p=272863#272863).

As mentioned above an option in the copy dialog which is disabled sometimes means not disabled, but don't change the state of the option in the BTM. Mr. Ghisler said about this:

The main problem is that when you used the pinned dialog, it's not clear whether TC should reset the overwrite options to those in the dialog, or use the last settings of the BTM. It's clear when the user clicks on "Options" himself.

Mr. Ghisler finds it logical that if the users clicks on the Options button or clicks on an option in the Advanced options section, the user wants to reset options to those in the dialog. When the options are merely shown, Mr. Ghisler sometimes assumes the user doesn't want the displayed options used, but instead not to reset the options in the BTM.

In my opinion the options displayed in the copy dialog should always be used for the copy operation. Furthermore for any options not displayed, I think default options as set in configuration should be used.

What also should be considered is what should happen when the user clicks on buttons like "Overwrite All" or "Skip All" when prompted before overwriting files. For normal copy operations the choice made by the user is valid for the remainder of the copy operation. In the BTM you can have multiple queued copy operations and the choice of the user extends to following copy operations until overwrite options are reset by certain copyflags lines. Many questions could be raised like:
* Should the choice made by the user (e.g. to overwrite all) extend to following queued operations?
* And what about new operations added to the queue?
* Should the choice by the user take precedence over preset choices in copyflags lines? If so, exactly what takes precedence over what?
* How can things be implemented without breaking compatibility?

When thinking about the BTM one should also realize that (a separate instance of) the BTM is also used for 'download lists' or 'Total Commander batch files' as I call it.

I think it would be ideal if copyflags are not queued but processed immediately by the BTM. Operations (for example copy operations) should be queued as jobs including all possible options. That way moving a job in the queue up or down would not effect operation of the job. Each job line should have some visible indicators corresponding to important options. All options of a job or group of jobs should be easy to view and change by the user.

Please give your opinion.
If you have any questions please ask and I will try to answer.

[gdpr deleted 6]

I think it would be ideal if copyflags are not queued but processed immediately by the BTM. Operations (for example copy operations) should be queued as jobs including all possible options. That way moving a job in the queue up or down would not effect operation of the job. Each job line should have some visible indicators corresponding to important options. All options of a job or group of jobs should be easy to view and change by the user.

I agree. While this approach might perhaps require some efforts, it basically eliminates the issues the BTM currently has.

What i would add is that the change of the job options should not be done by just clicking on the indicators (a-ka the indicators should not have checkbox or radiobutton semantics). Rather, a small job options dialog should be used for this purpose. This avoids "mouse-click accidents". Using tri-state checkboxes in this job options dialog would also allow changing the options of multiple jobs at once.

Regarding the situation where the user selects "Overwrite All" or "Skip All" when prompted by the BTM before overwriting files, i think the following should happen based on your suggested solution: The selected action will be assigned to all job lines currently in the queue (with the visual indicators being properly updated). However, it should not be forced upon any subsequently added jobs.

[gdpr deleted 6]

* Should the choice by the user take precedence over preset choices in copyflags lines? If so, exactly what takes precedence over what?

User choice always takes precedence over preset choices. UI design 101.

If not, "User choice" would be a fallacy, a lie. Or, in an attempt of abusing your words: "Should the <void> take precedence over preset choices in copyflags lines?"

[MVV]

I actually like that TC shows copy flags (I noticed it only recently) before the operation, but numbers aren't clear. It would be better to use letters (e.g. V for verify, OA/OO/SA/SO for overwrite/skip etc.) described in help. Maybe it would be better to see flags on the line with file but it will increase line length...

Also it would be useful to notice user that active BTM will copy/move w/o confirmation but every-time confirmations or notifications will be annoying. If BTM window is visible (not covered by other windows), it may show some notification but if it is covered by other windows user may miss such warning so it should be included into copy dialog, but here TC doesn't know will user use BTM or not...

[gdpr deleted 6]

It would be better to use letters (e.g. V for verify, OA/OO/SA/SO for overwrite/skip etc.) described in help. Maybe it would be better to see flags on the line with file but it will increase line length...

That would be the indicators @white was speaking about (whether @white imagined little icons, letters like you or something else would be a minor detail only regarding the scope of the discussion.)
The line length should not be a concern, unless you have a peep hole-sized display.

Also it would be useful to notice user that active BTM will copy/move w/o confirmation but every-time confirmations or notifications will be annoying. If BTM window is visible (not covered by other windows), it may show some notification but if it is covered by other windows user may miss such warning so it should be included into copy dialog, but here TC doesn't know will user use BTM or not...

That actually will be a non-issue if TC would treat "Overwrite all" semantically correct.

If you select "Overwrite all" in the F5 copy dialog, or you select it when being prompted before overwriting files in a F5 copy operation, it means to apply this action to all files selected for the current copy action (=scope of the F5 copy operation at the time of the prompt).

If you select "Overwrite all" when being prompted by the BTM, it means to apply this action to all files in the current BTM queue (=scope of the BTM queue at the time of the prompt).

You would not need to have additional confirmations, as (1) the scope of the "Overwrite all" action is always unambiguous and understandable to the user, and (2) it does not have any impact on future copy jobs/actions.

[MVV]

If you select "Overwrite all" when being prompted by the BTM, it means to apply this action to all files in the current BTM queue (=scope of the BTM queue at the time of the prompt).

You would not need to have additional confirmations, as (1) the scope of the "Overwrite all" action is always unambiguous and understandable to the user, and (2) it does not have any impact on future copy jobs/actions.

In such case you will be prompted for every single file that you will queue after queue is empty, and that's what Christian tried to avoid...

[white]

What i would add is that the change of the job options should not be done by just clicking on the indicators (a-ka the indicators should not have checkbox or radiobutton semantics). Rather, a small job options dialog should be used for this purpose. This avoids "mouse-click accidents". Using tri-state checkboxes in this job options dialog would also allow changing the options of multiple jobs at once.

This is exactly what I had in mind.

Regarding the situation where the user selects "Overwrite All" or "Skip All" when prompted by the BTM before overwriting files, i think the following should happen based on your suggested solution: The selected action will be assigned to all job lines currently in the queue (with the visual indicators being properly updated). However, it should not be forced upon any subsequently added jobs.

Also what I had in mind except that one might argue that "Overwrite All" or "Skip All" were meant for the current job only. Is the user aware his choice also applies to other jobs? What if the user only wants to overwrite all for the current job? Perhaps the user should have both options. In any case the user should be completely aware of what he is doing.

Applying the user's choice to "Overwrite All" or "Skip All" also to the remaining jobs is more dangerous. Perhaps clicking on "Overwrite All" or "Skip All" should only apply to the current job and when clicking the buttons while holding down one or more modifier keys (Shift,Ctrl,Alt) should extend the choice to the remaining jobs. In that case holding down the modifier key(s) should also visually alter the buttons.

* Should the choice by the user take precedence over preset choices in copyflags lines? If so, exactly what takes precedence over what?

User choice always takes precedence over preset choices. UI design 101.

If not, "User choice" would be a fallacy, a lie. Or, in an attempt of abusing your words: "Should the <void> take precedence over preset choices in copyflags lines?"

Considering my suggested solution this indeed makes less sense. In the current situation however you can have options set explicitly or not and the user's choice does not override the preset choices.

Then there is the question what should override what? For example, should "Skip all" override a preset choice to "Overwrite all"?

[gdpr deleted 6]

If you select "Overwrite all" when being prompted by the BTM, it means to apply this action to all files in the current BTM queue (=scope of the BTM queue at the time of the prompt).

You would not need to have additional confirmations, as (1) the scope of the "Overwrite all" action is always unambiguous and understandable to the user, and (2) it does not have any impact on future copy jobs/actions.

In such case you will be prompted for every single file that you will queue after queue is empty, and that's what Christian tried to avoid...

See @White's post above and my response below. I hope that covers the "Annoyance" issue.

[gdpr deleted 6]

Also what I had in mind except that one might argue that "Overwrite All" or "Skip All" were meant for the current job only. Is the user aware his choice also applies to other jobs? What if the user only wants to overwrite all for the current job? Perhaps the user should have both options. In any case the user should be completely aware of what he is doing.

Yes. On top of that, you might want to also consider "Overwrite all" only for specific transfer types. For example: "Overwrite all" only for ftp downloads, but not for local file copy/move jobs.

Also, a button in the prompt dialog to pause the BTM queue (+closing the prompt dialog) might be beneficial. This allows the user to stop the BTM when prompted to inspect what's going on and make an informed decision. After all, the user might have added the affected job(s) 30 minutes ago, and needs to double-check the situation.

Applying the user's choice to "Overwrite All" or "Skip All" also to the remaining jobs is more dangerous. Perhaps clicking on "Overwrite All" or "Skip All" should only apply to the current job and when clicking the buttons while holding down one or more modifier keys (Shift,Ctrl,Alt) should extend the choice to the remaining jobs. In that case holding down the modifier key(s) should also visually alter the buttons.

Yupp, that would be a possibility, and would also address the "annoyance" issue. (Instead of/Additionally to using keys you might also think about using "combobox buttons" or whatever they are called. But this is a just a design detail, though).

(EDIT: "ComboBox buttons" are in reality called SplitButtons)

Considering my suggestion solution this indeed makes less sense. In the current situation however you can have options set explicitly or not and the user's choice does not override the preset choices.

Yes, the current situation with the F5 copy options... is a big contributor to the mess the BTM is now. It is sort of backwards now.

Then there is the question what should override what? For example, should "Skip all" override a preset choice to "Overwrite all"?

Perhaps a separate button in the F5 copy options dialog for (re)setting the options to their preset value might be a quick'n'dirty way out of this conundrum.
It would eliminate the problem of the user's F5 copy options fighting with the preset options, while keeping the user still in control. (In any case, this should only be an intermediate solution.)

[MVV]

In any case the user should be completely aware of what he is doing.

Absolutely.

In that case holding down the modifier key(s) should also visually alter the buttons.

Additional confirmation may be added when user clicks button with modificator key...

Then there is the question what should override what? For example, should "Skip all" override a preset choice to "Overwrite all"?

Answer is simple, I think. Mode should be changed since currently added job. And, here copyflags line would be useful (or per-line mode letters/icons).

It might be a good idea to disable per-job flags by default at all 'cause it is a very dangerous feature...

[white]

If you select "Overwrite all" when being prompted by the BTM, it means to apply this action to all files in the current BTM queue (=scope of the BTM queue at the time of the prompt).

You would not need to have additional confirmations, as (1) the scope of the "Overwrite all" action is always unambiguous and understandable to the user, and (2) it does not have any impact on future copy jobs/actions.

In such case you will be prompted for every single file that you will queue after queue is empty, and that's what Christian tried to avoid...

In that case the help file should read about the Overwrite all button in the Overwrite dialog:

Files will be overwritten without warning from now on. In case this dialog was prompted by an operation in a Background Transfer Manager window: Files will be overwritten without warning for the current operation and possibly for the following queued operations. And the default option in the copy dialog is temporarily changed to Overwrite all for queued operations, if and for as long as this Background Transfer Manager window is the last opened and still open Background Transfer Manager window.

I doubt that anyone wants this

Considering my suggestion solution this indeed makes less sense. In the current situation however you can have options set explicitly or not and the user's choice does not override the preset choices.

Yes, the current situation with the F5 copy options... is a big contributor to the mess the BTM is now. It is sort of backwards now.

Then there is the question what should override what? For example, should "Skip all" override a preset choice to "Overwrite all"?

Perhaps a separate button in the F5 copy options dialog for (re)setting the options to their preset value might be a quick'n'dirty way out of this conundrum.
It would eliminate the problem of the user's F5 copy options fighting with the preset options, while keeping the user still in control. (In any case, this should only be an intermediate solution.)

In the current beta the options are already set to the default options saved in configuration. So this is not a problem. I was referring to something else, see below.

Then there is the question what should override what? For example, should "Skip all" override a preset choice to "Overwrite all"?

Answer is simple, I think. Mode should be changed since currently added job. And, here copyflags line would be useful (or per-line mode letters/icons).

I agree. I actually meant should a Skip all button in an overwrite dialog override Overwrite all settings in following queued jobs?

It might be a good idea to disable per-job flags by default at all 'cause it is a very dangerous feature...

That may be easier said then done.
Also, in case the feature is enabled, it still needs changes.

I am glad you agree that the current situation is not safe. It contrasts sharply with having all those confirmation dialogs.

[ghisler(Author)]

Sorry but this is fully intentional, it has ALWAYS been like this! It's only for the scenario where "Confirm overwrite" is the default, and the user adds files to an already open BTM. In this case, the state of the BTM will not be changed, e.g. when the user was confirming each file separately, it will remain this way. If, however, the user chose "Overwrite all" in the BTM itself, this will remain active. If the user chose "Confirm overwrite" manually in the F5 copy dialog, then this will of course be sent to the BTM too!

[MVV]

ghisler,
Even if it has always been like this, it should be changed. It is really dangerous. You usually prefer safe ways of doing something so it is strange why this thing works this unsafe way...
It is much safer to show a confirmation again than to use such undocumented side effect.

[white]

Sorry but this is fully intentional, it has ALWAYS been like this!

All the more reason to change it as soon as possible.

I wrote some more arguments in this post.

[nsp]

I personally think that a real queue manager is missing with session concept, better log, and a queue/batch editor that recap flags/operation,.....

This feature is really missing, and could be there if the BTM is enhanced and if a real focus on background operation is done. I personally use TC for foreground operation but for massive background operation I prefer other ways..... I suspect that BTM (background operation) is not the favorite piece of interest of M. Ghisler...

I also have some trouble with the Background Transfer window that do not show-up on time. Sometime because i just minimized the window i get wrong result of copy operation.

- - - -
I keep in mind that TC is doing very well foreground operations but lack in background and massive operations... I could be fantastic if the gap would be filled but I'm too old to keep waiting for Santa C.