TC11.00beta7 issue with SyncDirs

[georgeb]

2georgeb, you only accept your own logic, which is not followed by any other user.
You have to live with the sync function as designed, or try another tool.

I'm always ready to follow sound argumentation if it turns out to be conclusive! So as for this topic let's agree to disagree.

[Hacker]

georgeb,

It reminds me of "explanations" of "Hollow-Earth-Models" where the "explanations" keep on coming - but even the 20th of them couldn't convince me because it's already the premises that are flawed.
[...]
Planet Earth is a convex, oblate spheroid, my friend! No explaining away possible.

Have you ever considered it is you who keeps explaining that the only way it all makes sense is if the Earth is hollow?
Apart from that - if you have a good, well thought out and internally consistent concept on how to improve the Sync dirs functionality, feel free to post a suggestion in the Suggestions forum. The better thought out the concept, the higher the chance of implementing. If you have a way of creating GUI mockups, even better. Perhaps this way you can sway more people.

Roman

[petermad]

2georgeb

If you don't want TC to assume that newer files shall "survive", then just use the "ignore date" option (that IS what this option is for) - then all files with the same name and size will be marked as equal, and you can select manually if you want them to be copied (you have to have the [=] button enabled).

If you don't want to manually compare all files with the same name and size, to see which ones you want to copy, then you can additionally use the option "by content", then it is only the files marked with red, that you have to decide where to copy or not.

[Dalai]

In this case SyncDir makes the (uninformed) decision that the newer file is meant to "survive".

Of course it does. What is it supposed to do instead? File names are compared and then size and date. Which other conclusion should TC make based on those parameters?

And while this may be true for 90% of the cases - this needn't always be the case. Sometimes newer versions will turn out to having been nothing but meandering or a simple trial-balloon.

This can be the case, and in my work with TC this has occured many times, but certainly not in the majority of cases. The user can change anything the sync tool suggests. So I don't see a problem here.

NB: I'm gonna make it even more complex, or illogical was you would probably call it , because I missed a case in which the red color is used: asymmetric mode. In this case unique files on the right are marked this way to be deleted.

Regards
Dalai

[JOUBE]

tl;dr. But...

the green selection-button (corresponding to "unique left")

...it's not true that green means "unique left". So, there are already information deficits in the first posting. Did you at least clear that up in the meantime?

Joube

[petermad]

it's not true that green means "unique left"

Exactly what I tried to point out here: https://ghisler.ch/board/viewtopic.php?p=435027#p435027

Green (arrow AND file name color) means: suggested to be copied from left to right.

From the Help:

<File list> Here the compared directories are shown, and (if chosen by the user) also their subdirectories. Each subdirectory is delimited by a gray bar. The symbol in the middle defines the copy direction, which can be chosen by the end user. The coloring of the text defines the default copy direction determined by the comparison:
Green: Copy from left to right
Blue: Copy from right to left, or delete on the right side (asymmetric mode, in this case, the file has a cross symbol x in the middle).
Red: Files which are different by the given criteria (no copy direction)
Black: Files which are identical (no copy direction)

In my opinion the functionality is exactly as described in the help.

Notice that even if the user manually changes the copy direction, the color of the text stays the same, so it is easy to see if you have overridden the suggested direction.

[georgeb]

Have you ever considered it is you who keeps explaining that the only way it all makes sense is if the Earth is hollow?

I've contemplated the whole situation multiple times and I'd still like to know which of my statements has been obviously erroneous (as HE-theories demonstrably are)?

Apart from that - if you have a good, well thought out and internally consistent concept on how to improve the Sync dirs functionality, feel free to post a suggestion in the Suggestions forum. The better thought out the concept, the higher the chance of implementing. If you have a way of creating GUI mockups, even better. Perhaps this way you can sway more people.

As it happens I've indeed introduced a generalized, more versatile variant of the SyncDirs-tool some time ago that would be capable of primarily consolidating folders containing different versions of files instead of only syncing them. This more generalized method wouldn't even primarily rely on filenames anymore but rather check all files of same size for binary equality thereby being able to cope with even moved/renamed files/dupes somewhere else..

Although I'll have to admit that the reaction has been lukewarm at best (with the exception of some of "the gang" here, including a certain well-esteemed moderator )
viewtopic.php?p=425346#p425346

[georgeb]

2georgeb

If you don't want TC to assume that newer files shall "survive", then just use the "ignore date" option (that IS what this option is for) - then all files with the same name and size will be marked as equal, and you can select manually if you want them to be copied (you have to have the [=] button enabled).

If you don't want to manually compare all files with the same name and size, to see which ones you want to copy, then you can additionally use the option "by content", then it is only the files marked with red, that you have to decide where to copy or not.

Yes, I already knew that. As already mentioned before with both the "ignore date"- and "by content"-options enabled is the only way I've used SyncDirs for so many times. And I dare say it's the only way of using it I deem reasonable without producing contradictory, illogical results - but then every user is free to choose for himself.

[georgeb]

Of course it does. What is it supposed to do instead? File names are compared and then size and date. Which other conclusion should TC make based on those parameters?

As now explained for many times it could only SUGGEST a selection via the arrow-symbol while still indicating (by font-color) whether or not different versions of these files exist on the other side and if so alert the user that maybe he might want to decide for himself on an individual basis

[Dalai]

So what would the (colored) buttons filter by? Font color or arrow color? Either way, this makes the whole shebang even more complex. I hope you also understand that users would have to look for a pretty small indicator what TC is suggesting to do with the files instead of seeing the sync direction at first glance.

Regards
Dalai

[georgeb]

.it's not true that green means "unique left". So, there are already information deficits in the first posting. Did you at least clear that up in the meantime?

Again and again and again: I'm fully aware that this isn't true NOW! But it OUGHT TO BE TRUE for logical reasons! The mere pre-selection for copying could perfectly well be represented by the ACCORDINGLY COLORED ARROW-SYMBOL ALONE! It cannot be THAT hard to comprehend!

[georgeb]

Exactly what I tried to point out here: https://ghisler.ch/board/viewtopic.php?p=435027#p435027

Green (arrow AND file name color) means: suggested to be copied from left to right.

In my opinion the functionality is exactly as described in the help.

YES! I FULLY DID CONCEDE THAT - and still do! But - again and again - for logical and information-quality reasons THIS SHOULD NOT BE THE CASE! It can lead to quite misleading results thereby DEPRIVING THE USER OF CRITICAL INFORMATION!!! Heavens! It can't be that hard to understand that those two representations (font-color and arrow-symbol) COULD -AND SHOULD BE - EASILY DECOUPLED! The colored arrow-symbol ALONE would be perfectly sufficient to indicate the suggested copying-direction!

That way the green or (then also) red font-color could further indicate (in spite of the pre-determined selection for copying) whether or not "different" files/versions-thereof do exist on the other side - in accordance with the bottom status-bar-summary. I consider this to be absolutely critical information that the USER MUST HAVE in order to decide for himself whether or not he might want to accept this pre-determined selection for copying as suggested by the system WITHOUT INDIVIDUAL VISUAL INSPECTION of those de-facto "different" file-versions. If all is colored in green (because of the mere pre-selected direction for copying) - how then could the user find out that different versions of those files DO EXIST without consulting a crystal-ball?

[georgeb]

So what would the (colored) buttons filter by? Font color or arrow color? Either way, this makes the whole shebang even more complex. I hope you also understand that users would have to look for a pretty small indicator what TC is suggesting to do with the files instead of seeing the sync direction at first glance.

Font-color = actual category these files belong to of course! Isn't it odd that - as it stands now - all may be represented in green (because of the mere pre-selected direction for copying) while at the same time the bottom-status-bar may indicate a considerable number of different files with no corresponding representation in the main window at all? As you've correctly pointed out yourself before there may be no red color present in the main display at all WHILE THERE ARE STILL FILES IDENTIFIED AS BELONGING TO THE CATEGORY "DIFFERENT" by the system (according to status-bar) thereby denying the user the ability to de-/select them by the corresponding top-red-selection-button which in this case would be rendered inoperable/defunct? IMHO that sounds like an example of a logical "TriBar".

As for the small indicator - the user would primarily and at a glance recognize the basic file-category (perhaps being "different"/red) and therefore rightfully be warned to use caution and re-check the copying-direction manually/visually - whereas with the truly singular (green- or blue-font) files he wouldn't have to worry as much! In the end it doesn't help a lot if the user is lulled into a false sense of security and simplicity by the system wrongfully applying undifferentiated green color.

[Dalai]

Isn't it odd that - as it stands now - all may be represented in green (because of the mere pre-selected direction for copying) while at the same time the bottom-status-bar may indicate a considerable number of different files with no corresponding representation in the main window at all?

Why do you think there's no corresponding information in the list above the status bar? It's just that there is no 1:1 relation as I explained several times now. Maybe it's best if you ignore the information in the status bar altogether unless you really need it. Usually I don't look at these numbers because what matters is what TC is going to do with the files, i.e. which direction they're going to be copied or deleted. And for that the buttons above the list are much more important and useful.

As you've correctly pointed out yourself before there may be no red color present in the main display at all WHILE THERE ARE STILL FILES IDENTIFIED AS BELONGING TO THE CATEGORY "DIFFERENT" by the system (according to status-bar) thereby denying the user the ability to de-/select them by the corresponding top-red-selection-button which in this case would be rendered inoperable/defunct?

If you need to see unique files, deselect "doubles" and TC will show only files that exist on both sides, i.e. are different by your definition - simple as that.

As for the small indicator - the user would primarily and at a glance recognize the basic file-category (perhaps being "different"/red)

So users would have to look for small green or blue indicators in a sea of red text. Doesn't sound easy or a smart design to me.

Regards
Dalai

[petermad]

If you need to see unique files, deselect "doubles" and TC will show only files that exist on both sides,

Don't you mean:
If you need to see unique files, deselect "doubles" and TC will show only files that exist on one of the sides.
or:
If you need to see unique files, deselect "doubles" and TC will not show files that exist on both sides.