+[TC8.50b6] BTM and Overwrite / Skip All

[Hacker]

romulous,
All users (well, 99%) are trying to help improve the software. Opinions differ, that is normal. Sometimes they are more vocal, sometimes less. That is normal, too. That's all.

Roman

[ghisler(Author)]

There is now a new option in wincmd.ini which allows you to control the overwrite behaviour:

BackgroundCopyFlags=1

Controls the overwrite behaviour of the background transfer manager:
0: When the user chooses one of the overwrite options, e.g. "Overwrite all", the option remains active also when adding more files to the transfer manager later (behaviour of TC 8.01 or older)
1: Reset the overwrite options when the transfer manager list reaches the end
2: Reset the overwrite options each time the user adds more files to the transfer manager (always confirm again)

[gdpr deleted 6]

Great, thank you!
I will try out

Just two more questions out of curiosity:

If the option is missing from the INI file, then the default value would be "0", correct?
Would a new, fresh installations of TC include this option in the default INI file, and if so, what would be its value?

[white]

Great, thank you!

There is nothing great about it. It adds to the complexity causing more problems. Also, option 0 is NOT the behaviour of TC 8.01 or older. Both option 0 and 1 contain a change introduced in beta 6 making it less secure. I strongly suggest people not to update unless they know what they are doing.

If the option is missing from the INI file, then the default value would be "0", correct?

No, "BackgroundCopyFlags=1" means 1 is default. So, when the option is missing value will be 1.

Would a new, fresh installations of TC include this option in the default INI file, and if so, what would be its value?

No, after the installer the INI only contains:

Code: Select all

[Configuration]
InstallDir=<folder>

After first launch a few options are added, BackgroundCopyFlags is not one of them.

[ghisler(Author)]

2elgonzo
No, the default is 1, as listed in the help. This is a compromise between "ask always" and the old "just ask once".

[gdpr deleted 6]

I find this option to be really an improvement. However, i would recommend to use BackgroundCopyFlags=2 as default, if no explicit BackgroundCopyFlags option is given in the INI, because it is on the safe side. I my opinion, it would be worth putting a minor one-time annoyance onto the existing knowledgeable BTM users by asking them to manually set BackgroundCopyFlags to their liking.
However, this is just my opinion. (After all, the fact remains that this F2 queue is already working the way it did since TC6.0(?), i guess; making it a bit of a surprise to me that nobody else before stumbled over this issue.)

Perhaps, if potentially annoying a part of the user base is too risky, how about doing something like you did with the default font:
If no wincmd.ini/[Configuration] section could not be found (a-ka new installation), use default value of BackgroundCopyFlags=2.
If [Configuration] section already exists (a-ka existing user / updated installation), use a default value of BackgroundCopyFlags=1.

[ghisler(Author)]

Also, option 0 is NOT the behaviour of TC 8.01 or older. Both option 0 and 1 contain a change introduced in beta 6 making it less secure.

This isn't true. TC 8.0 was not passing the copyflags to the BTM when adding new files and the "Options" were not expanded, or they were and the user didn't change anything.

[white]

BackgroundCopyFlags=1: Reset the overwrite options when the transfer manager list reaches the end

A more useful option would be: When the user chooses one of the overwrite all/skip all/auto-rename options in a dialog prompted by the BTM, reset the options at the end of the current list (confirmation is asked again for new entries).

I find this option to be really an improvement. However, i would recommend to use BackgroundCopyFlags=2 as default, if no explicit BackgroundCopyFlags option is given in the INI, because it is on the safe side.

Indeed, BackgroundCopyFlags=2 is the only safe option.

However, this is just my opinion. (After all, the fact remains that this F2 queue is already working the way it did since TC6.0(?), i guess; making it a bit of a surprise to me that nobody else before stumbled over this issue.)

Yes, the F2 Queue button was introduced in TC 6.0 and it has been working like this for a long time. But that is not a valid reason for not changing a dangerous situation. It's like having a dangerous intersection and saying we are not going to change it because it always has been like this and we haven't received reports of fatal accidents. Apparently people need to report the loss of data first.

I think it is safe to assume that data did get overwritten unexpectedly. Why it hasn't been reported yet can have lots of reasons. People may never have noticed it, did not know Total Commander was involved, did not understand why it happened, felt embarrassed, didn't care, didn't take the trouble of writing a report, etc.

If very important data did get lost and people knew or suspected Total Commander was involved, I think it's more likely they would never touch Total Commander again, rather than that they would report the issue.

The operation of the copy dialog in relation to the BTM relies on the user being constantly aware which BTM windows are still open and what the status is of the overwrite options at the end of the queue in each BTM window. As discussed elsewhere, this is impossible. Also, we want the computer to help us so we don't have to be constantly aware of everything. That's why confirmation dialogs are shown. The computer should help us to make less mistakes, not make the chance of making mistakes bigger. It's also totally unnecessary. It is simply a matter of design.

I think when the user is annoyed by many overwrite dialogs, he might expect his choice to overwrite all to extend to all following entries in the BTM. When the user is shocked because his data was overwritten unexpectedly, he might expect his choice to overwrite all to be only valid for the current entry in the BTM. Fact is, that "Overwrite all" is ambiguous. It can mean for current job only, also for part of the queue, also for the entire queue, also for new entries added to the queue.

One should also be aware that the behavior of the BTM applies to all "... all" choices. While Overwrite all and Skip all may make some sense, it is very unlikely when the user chooses "Overwrite all bigger" or "Auto-rename target files", that he wants this for all entries in the queue.

The only decent thing to do is to make things explicit (the user must explicitly tell if his choice is meant for current job or for queue) and to document properly.

In my opinion the full operation of the BTM is not intuitive, too complex, ambiguous and undocumented. Just adding more configuration options makes it worse. It's going down the wrong road.

Also, option 0 is NOT the behavior of TC 8.01 or older. Both option 0 and 1 contain a change introduced in beta 6 making it less secure.

This isn't true. TC 8.0 was not passing the copyflags to the BTM when adding new files and the "Options" were not expanded, or they were and the user didn't change anything.

• 17.11.03 Release Total Commander 6.0
  The F2 (Queue) is added to copy dialog.
  Copyflags are sent/options in the BTM are reset when an option is selected using the Options button. Merely clicking the Options button does not reset options in the BTM.
• 09.09.09 Release Total Commander 7.50
  The Options button in the copy dialog is moved to the bottom and clicking it adds advanced options to the dialog.
  Options in the BTM are reset when the user clicks on the Options button showing advanced options.
• 17.06.10 Release Total Commander 7.55
  A pin is added to the copy dialog which pins down advanced options.
  Options in the BTM are reset when the user clicks on the Options button or on one of the advanced options. If advanced options were pinned down and the user does not click on one of the advanced options, options in the BTM are not reset.
• 29.11.10 Release Total Commander 7.56
  Options in the BTM are reset whenever advanced options are shown in the copy dialog. Either by clicking the Options button or when the advanced options were pinned down.
• 16.10.13 Release Total Commander 8.50 public beta 6
  Change back to the situation in Total Commander 7.55.

So, apart from 6 months during version 7.55, whenever advanced options are shown, these options are used for the copy operation. If the copy dialog says confirmation is asked before overwriting files, this will always be the case. Also when the operation is queued to the BTM. It has been like this for the last 3 years. You are now changing this behavior and saying nothing has changed.

[ghisler(Author)]

Are you sure about that? I'm not aware of this change in TC 7.56. If this is preferred, I will use this also in option 0 and 1 if the dialog is expanded. The intention was that the flags are only sent when something is changed in the Options section, so something must have gone wrong in 7.56...

[white]

Are you sure about that? I'm not aware of this change in TC 7.56.

Yes, I'm sure.

[ghisler(Author)]

OK, I found out something: The problem is with the CopyOverwriteDefault option in wincmd.ini: This can be set to values 1..8 to correspond to what the user has chosen in the dialog box. Initially this was set to CopyOverwriteDefault=0 when it was missing, which means the behaviour in TC 7.55 - this is how it was intended to be. sometimes during the development of TC 7.56, I must have changed the default to CopyOverwriteDefault=1 - which is the behaviour of TC 7.56, 7.57 and 8.0x (flags get reset when Options part is open).

So i will return to this behaviour in beta 8: Set CopyOverwriteDefault=1 as the default and reset the flags when options is open as in TC 8.01. The user can still set CopyOverwriteDefault=0 to get the current beta behaviour.

[white]

So i will return to this behaviour in beta 8: Set CopyOverwriteDefault=1 as the default and reset the flags when options is open as in TC 8.01. The user can still set CopyOverwriteDefault=0 to get the current beta behaviour.

Already confirmed in other thread.