TC11.00beta7 issue with SyncDirs

[petermad]

2georgeb

It found the culprit - you must have the parameter 1hourdif=1 in your "production" wincmd.ini.

With this parameter set to 1 you will get more identical files if their size is the same and the time differene is 1 hour

Try and put 1hourdif=1 in your "virgin" wincmd.ini, and see if you now get the same result as with your "production" wincmd.ini.

[georgeb]

And still your Folder tabs were preserved - that is contradictory ???

You're absolutely right! Contradictory that sounds indeed - and yet it is the case, having been checked and double-checked.

[georgeb]

Ok, thanks for all the dedicated advice. After having completed my tests, and Yes!, including "/i=%TEMP%\virgin.ini", I can summarize as follows:

Problem - at least from my point of view - not really solved but presumably not a bug either.

First observation: trying to start TC with parameter "/i=%TEMP%\virgin.ini" resulted in quite a different (almost non-existent) 'wincmd.ini' located deep in the weeds of the User-Appdata-subDir with a size of only 309 bytes containing only chapter-headings. Needless to say that no saved tab-structure could have been contained in there while the pseudo-"virgin"-'wincmd.ini' auto-generated by TC upon re-start - after correctly and successfully having deleted its own 'wincmd.ini' (it was definitely absent before TC-restart, Help said after re-start that the 'wincmd.ini'-Dir was the very same as the program-Dir) - had a considerable size of 22651 bytes and STILL DID CONTAIN the familiar tab-structure from the 'production-version' while other than that being stripped of mostly all individualizations declared in the latter. Since all the installation- and 'wincmd'-Dir-settings turned out to be clearly separated (under guarantee) there still has to be an active hidden side-effect where this info is gained from by TC atomatically.

As for SyncDirs the results were again as bad as described before, even with the "/i=%TEMP%\virgin.ini"-method, but I think I now have at least an idea how this could have come about.

In my "production-version" of TC I'm used to always having checked "by content" and "ignore date" when performing any SyncDirs-process. These pre-sets were obviously gone when doing my test-run with the clean installation of TC and while I am absolutely certain that "by content" had been selected again I'm not so sure about "ignore date" anymore.

As it has now turned out upon closer inspection with only "ignore date" turned off any binary-identical-files with identical names but NEWER file-dates, as well as binary-DIFFERENT-NEWER-files, even with the "by content"-option enabled, will be (wrongfully) listed as "unique left" in the main window albeit the number of binary-truly-unique files as well as the number of binary-truly-different files will still be given correctly in the bottom-status-bar. The top-red button for de-/selecting binary different files is thereby rendered inoperable. I find this behavior to be most unfortunate, again contradictory and heavily misleading at the same time - but it will be the same across all versions and installed instances of TC. So this case about a possible bug that would need to be fixed in the short term can be closed as of now.

"IT'S NOT A BUG, IT'S A FEATURE!"

[georgeb]

It found the culprit - you must have the parameter 1hourdif=1 in your "production" wincmd.ini.

With this parameter set to 1 you will get more identical files if their size is the same and the time differene is 1 hour.

How would you know? Yes, that parameter is set to "1" in my production-wincmd.ini - but after my recent experiments I don't think it would make much of a difference. The problem - as I see it - is rooted in the questionable way SyncDirs interprets the "unique left/right"-status as soon as "ignore date" somehow would become unchecked. As I've practically never worked with that option I really have been unaware of the dramatic consequences the de-selection thereof would implicate.

Yet as long as both options "by content" AND "ignore date" are reliably checked in the Sync-Dirs-dialog the process - as it stands now - will work as expected (at least by me), even when run on a "virgin"-TC-instance. I guess it has been kind of a false alarm caused by my consternation when observing that questionable and from my point of view odd behavior for the first time.

[petermad]

but after my recent experiments I don't think it would make much of a difference.

Here it makes all the difference - please try to use the same setting for 1hourdif in both your ini's and see if it doesn't then give the same sync results (with options "by content" AND "ignore date" disabled)

...that with the virgin instance of TC11b7 with an equally virgin "wincmd.ini" both the 32 "different files" AND the 5 files "unique left" came up in green color (indicating "unique left") and pre-selected for copying left to right. None of the 32 "different files" could be de-/selected via the corresponding red selection-button at the top while the green selection-button (corresponding to "unique left") now erroneously would make all 37 files go away or re-appear altogether.

I reread the above from your first post - files marked with green arrow are NOT the same as "unique left". Green marks both "unique left" files AND files on the left side that has the same name and size, but are newer than the file on the right side.

That is also why 1hourdif= changes the result if the files on the left and right have the same size but the time differs with 1 hour - with 1hourdif=0 those files are seen as different, hence marked with green arrow, with 1hourdif=1 the files are seen as equal, hence marked with black =.

The file time can differ with 1 hour if the files are put at their location before and after daylight time saving change.

[georgeb]

Here it makes all the difference - please try to use the same setting for 1hourdif in both your ini's and see if it doesn't then give the same sync results (with options "by content" AND "ignore date" disabled)

Yes, I will try. But although I haven't been aware of that subtle detail you've pointed out I fully understand what you mean and also the predicted consequences thereof for the number of files found in that category which may then differ. I don't even have to actually execute the experiment to envision the different outcome that is certain to follow. But the thing is that THIS IS NOT MY POINT!

I reread the above from your first post - files marked with green arrow are NOT the same as "unique left". Green marks both "unique left" files AND files on the left side that has the same name and size, but are newer than the file on the right side.

Now we're at the core of the flawed concept! Yes, a green arrow-mark only means "selected for copying from left to right" - and I'm fine with that. But the point is that these filenames on the left (if not identical) are also displayed in a green-color-font - which in accordance with the bottom status-bar INDEED OUGHT TO MEAN "UNIQUE LEFT"
And with both options "by content" and "ignore date" set the results will mostly indeed be "unique" (at least locally).
Also I'd like to draw your attention to the point that files in green-color-font ("unique left" according to status bar) will still be represented that way regardless of whether or not they are selected for copying at all.

And that is fine as long as they're truly unique, regardless of intended copying operations thereafter. Now what is really unacceptable from a logical point of view is - when "ignore date" is not enabled - that even binary-different files (the number of which is still correctly given in the status-bar and which therefore OUGHT TO BE REPRESENTED in red-color-font meaning 'binary different') are now represented in green color, too, (if only their date is newer) WHEN IN FACT THEY ARE NOT UNIQUE AT ALL but rather do have a binary-different counterpart/version on the other side and therefore OUGHT TO BE REPRESENTED in red-color-font as already mentioned.

With that unfortunate option-setting there will be no "red files" in the main display at all and therefore the top-selection-button in red for de-/selecting different files WILL BECOME MOOT in spite of the fact that the status-bar will still indicate the number of different files found - only that one cannot identify them any more because they will now come up "disguised" in green.

If the point of this setting is to only preserve newer files in the end-result then the correct representation would be red-colored-filenames (because of binary different versions) but with a green/blue arrow pointing from the newer side to the older in order to pre-select the newer version for overwriting the older one.

That is also why 1hourdif= changes the result if the files on the left and right have the same size but the time differs with 1 hour - with 1hourdif=0 those files are seen as different, hence marked with green arrow, with 1hourdif=1 the files are seen as equal, hence marked with black =.
The file time can differ with 1 hour if the files are put at their location before and after daylight time saving change.

That part is undisputed.

[petermad]

But the point is that these filenames on the left (if not identical) are also displayed in a green-color-font - which in accordance with the bottom status-bar INDEED OUGHT TO MEAN "UNIQUE LEFT"

No, the green colored files are represented in both "Different" AND "Unique left". Some of the "Different" files can have the same date+time but different size - then they are marked red. If a "Different" file has the same size, but the date is newer it is marked with green (otherwise with blue).

If you enable "by content" - then files with the same size, will be compared and if the content is different, they will be marked red. If the files are of different size, they will not be compared (unless you are using plugin-comparing), because files of different size can not be identical - in that case TC will look at the date and mark the newest for copying = green or blue.

If also you enable "ignore date" only Single files will be marked (green or blue) for copying. All other files will be marked with red if the sizes are not the same otherwise they will be marked as with black as Identical. That is because TC cannot determine the direction to copy duplicates without comparing the date+time.

[georgeb]

If also you enable "ignore date" only Single files will be marked (green or blue) for copying. All other files will be marked with red if the sizes are not the same otherwise they will be marked as with black as Identical. That is because TC cannot determine the direction to copy duplicates without comparing the date+time.

And that is the only way of operation that makes sense. When the status-bar says nnn files "unique left" this obviously has to correspond with the very same number of truly unique files in the main window. The selection for copying has to be regarded in a totally separate manner from the true nature of the files. "Unique" has to really mean "unique", there is very little wiggle-room about the meaning of that term - in fact almost none at all.

[petermad]

"Unique" has to really mean "unique", there is very little wiggle-room about the meaning of that term - in fact almost none at all.

A unique file is a file that either exists on the left side OR on the right side, but NOT at both sides - and that IS what the status line says

A different file is a file that exist on both sides and either has a different date OR a different size.

Maybe this can help illustrate it: https://tcmd.madsenworld.dk/synccategories.png

A unique file is the same as a single file

[georgeb]

A different file is a file that exist on both sides and either has a different date OR a different size.

Exactly! And precisely that is why - although such files can correctly show a green arrow when pre-selected for copying from left to right (for instance when they might be a newer version of their other-side-counterpart) - they MUST NOT BE REPRESENTED IN GREEN-COLOR-FONT as they clearly belong to the red-colored status-bar-category of "Different Files".

[Dalai]

You have to decouple the terms from the colors. Both red and green can mean "different" as you can see in petermad's screenshot.

Red is only used when the direction for synchronization can't be predetermined. This can occur

• if files have been compared by content (and date was ignored)
• if files have the same timestamp but different size
• or they haven't been compared by content at all because they're on a network location (e.g. FTP) or in an archive.

TC automatically determines the synchronization direction if possible, i.e. the date is different (and "ignore date" isn't checked).

Regards
Dalai

[georgeb]

You have to decouple the terms from the colors. Both red and green can mean "different" as you can see in petermad's screenshot.

Red is only used when the direction for synchronization can't be predetermined. This can occur

Yes, that's the way it works now. That is understood. But still it is a logical MIS-CONCEPT. There is no (good) reason why the pre-selected direction for copying couldn't be expressed by the arrows (and their color) alone. Arrows are inherently associated with a direction for a good reason - and rightfully so!

While at the same time THE TERMS (according to the 4 existing status-bar-categories) SHOULD NOT BE DECOUPLED FROM THE (FONT-)COLORS! Green-font-color really ought to mean "unique left", meaning with no different counterpart on the other side, whereas red-font-color ought to mean that a different counterpart/version-of-that-file would exist on the other side. That way also the total numbers of files found in each category (as given by the bottom status-bar for each category) would always correctly correspond to the sum of files represented in either green or red font.

In other words - it's a logical NO-GO that files represented in green-color-font ("unique") still may have different counterparts (with perhaps older file-dates or even different size) on the other side - as it is currently implemented.

[Dalai]

While at the same time THE TERMS (according to the 4 existing status-bar-categories) SHOULD NOT BE DECOUPLED FROM THE (FONT-)COLORS! Green-font-color really ought to mean "unique left" [...]

No, it doesn't and it shouldn't. The colors don't have a 1:1 relation with the status bar information, as petermad already explained. Different files are only what TC can't automatically determine the sync direction or if the user explicitely told TC to ignore date and/or compare by contents.

[...] whereas red-font-color ought to mean that a different counterpart/version-of-that-file would exist on the other side.

Are you aware that red color doesn't need to appear at all? For you as a user the files might be different, but that's not what "different" means in this context, as has been explained multiple times now. Different means "TC didn't make automatically set the sync direction" - for any of the reasons listed above.

Regards
Dalai

[Horst.Epp]

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.

[georgeb]

Are you aware that red color doesn't need to appear at all? For you as a user the files might be different, but that's not what "different" means in this context, as has been explained multiple times now.

It's not that I haven't fully understood those "multiple explanations" - it's just that that I'm not buying into them! So let us agree here to disagree. 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.

I'll give you a last example: Oh yes, I'm absolutely are aware that "red color doesn't need to appear at all". And it's part of the problem. As this is for instance the case when "ignore date" IS NOT selected and newer versions of a file (even with the same size) exist on one side together with true binary-unique, singular files. And this is exactly the problem that the SyncDir-process doesn't differentiate between those two categories but rather treats them by lumping them together.

In this case SyncDir makes the (uninformed) decision that the newer file is meant to "survive". 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.

So if TC dares to assume that this newer version is meant to survive the synchronization and should be kept in the final version - marking it with a BLUE OR GREEN ARROW would fully suffice to indicate that assumption.

But because the filename itself at the same time WOULD NOT APPEAR IN RED FONT but rather in green/blue-font, lumped together with the group of all the true singular files, THIS (MIS-)BEHAVIOR DEPRIVES THE USER OF THE CRITICAL INFORMATION that a different counterpart-, maybe older-version exists on the other side!!!

Remember, TC's assumption to keep the newer file is already sufficiently expressed by the green/blue ARROW. Now wouldn't it be great if SyncDirs would still differentiate between truly singular (green/blue font) and de-facto different files (red font) as they are counted in the bottom status-bar? Thereby finally advising the user that a different counterpart-/version-file DOES EXIST on the other side and the pre-selection for copying by SyncDir is just a suggestion while perhaps the user should better INTERACTIVELY look into both versions (compare them?) once again before making a final decision about which one to keep?

Planet Earth is a convex, oblate spheroid, my friend! No explaining away possible.