"Synchronize Directories" always uses filename

[nn1k3]

"Synchronize Directories" can only compare files with the same name.

SUGGESTION: add an option to compare by content while ignoring the name.

TC HELP wrongly suggests that is the current behavior:

Code: Select all

☑ by content: Compares the content of files which have the same size and date. It checks that the files also have the same content.

[fenix_productions]

Left dir with files: a.txt, b.txt and c.txt.
Right dir: c.txt, d.txt, e.txt f.txt.

How do you choose files to compare content if you ignore names?
I would understand if there would be a request for some matching name patterns* but either way you would need to compare every file on left with every file on right. This would be very, very time consuming.

*) Patterns: it would be nice to have a possibility of specifying name patterns in form of regex to show TC that two files have same name for content comparison like, for example:
For files:.
Left: c.txt
Right: c-backup.txt
I could use:
Regex1: (.*)([.]txt)
Regex2: $1-backup$2
Based on regex TC would assume names are the same and could compare those files by content.

It would be similar to "Unimportant Text" definitions in Beyond Compare.

[nn1k3]

Thank you Fenix for your reply.

Alt-F7 "find duplicate files" based on "same contents" does not take an intolerably long time. I presume it is efficient by first finding files of the same size and then comparing their MD5 checksums. So it does not have to laboriously compare the contents all of the possible pairings of files = n!/(2*(n-2)!). The resulting output list shows groups of files with the same MD5 checksum, which are assumed to be unique. (Please correct me if I am mistaken.)

I am only asking for that functionality to be enabled for Alt-CY "Synchronize Directories. That left-right comparison is extremely useful in deciding which duplicate to keep. When there are many duplicates I find it much easier to work with than the results of an Alt-F7 duplicates search.

[YeetDabMcFapDab]

"Synchronize Directories" can only compare files with the same name.

SUGGESTION: add an option to compare by content while ignoring the name.

TC HELP wrongly suggests that is the current behavior:

Code: Select all

☑ by content: Compares the content of files which have the same size and date. It checks that the files also have the same content.

CCcleaner does so by checking for the same size and content, but takes horribly long to scan the folders and is bloatware anyways so I'd prefer using TC to check for duplicates

[georgeb]

As I've suggested for multiple times in various locations by now I would precede such an operation by a standard "SyncDirs"-run to first narrow down the candidates for (renamed and/or moved) binary duplicates by excluding all the identical and already marked as different files first.

The current deficiency of "SyncDirs" lies in the fact that the so called "unique" files (left/right) are in fact only "pseudo-unique" as both columns may well contain binary duplicates with different names and/or moved to a different location, even with identical filenames.

What would be necessary to remedy this unfortunate situation is to enable/implement the capability for performing a second-step comparison-run (only on special user-demand and) only between those narrowed-down columns "unique (left/right)" which would now perform a genuine search for binary duplicates from within the "SyncDirs"-process, now disregarding filenames and arbitrarily looking for binary duplicates among all pairs of files of the same size (much as the duplicate-files-search from <Alt>F7 already does).

The goal of such a secondary comparison-run would be to split each of the primary columns "unique (left/right)" into two sub-categories being "TRULY unique (left/right)" (having no binary duplicates somewhere else) AND "only LOCALLY unique (left/right)" (for those files HAVING binary duplicates somewhere else). And of course those newly generated 4 columns would now need to be individually selectable. To achieve this I've suggested to now split the top-level-selection-buttons (green and blue) into 2 halves each, possibly colored "dark-blue" and "light blue" and "dark green"/"light green" respectively (or any other color-combination of Christian's liking) - where the dark-colored buttons would now select the "TRULY unique (left/right)"-categories whereas the light-colored buttons would now separately only select the newly found "only LOCALLY unique (left/right)"-categories, that is all those files with binary duplicates of arbitrary names someplace else.

And lastly - to reduce the complexity within the display of very large data-structures - it would be desirable to have a right-mouse-click-menu-option when clicking on any of the light-colored "pseudo-unique"-filenames to open up a new (pop-up?)-page SHOWING ONLY ALL THE BINARY DUPLICATES OF THAT VERY FILE, wherever they may have been found, but still within the well-proven sub-tree-structured display-mode of the "SyncDirs"-tool where each file would be listed beneath its parent-directory - and as opposed to the somewhat confusing and unclear non-structured display-mode of an endless list of (perhaps thousands of) file-pairs/-triples given without any tree-structure and with their paths only listed behind these names as is the case with the current <Alt>F7-style-duplicates-search.

So this in short would be my proposal to create an advanced and powerful "SyncDirs"-process also capable of handling binary-duplicates.

[ghisler(Author)]

"Synchronize Directories" can only compare files with the same name.

That's the whole point of the function - make the left and right side the same. Without the name check, there could be a one to many result, e.g. with a file and multiple backups of it.

[georgeb]

That's the whole point of the function - make the left and right side the same. Without the name check, there could be a one to many result, e.g. with a file and multiple backups of it.

So if this burns down to a formalistic naming-convention-discrepancy where "SyncDirs" is - per definition - only allowed to "make the left and right side the same" then I'd be more than happy to rechristen (re-Christian? ) my enhanced proposal into some parallel "Reconcile-and-Consolidate-Dirs"-tool to be hopefully implemented as an independant, parallel tool sometime in the (not too distant) future!

[ghisler(Author)]

It would always lead to mismatches. Example: Take a text editor which always stores the previous save as file.ext.bak
Starting point:
test.txt on both sides, identical.
Now the user edits test.txt on the left and saves it.
-> he has now two files on the left:
test.txt with new content
test.txt.bak which is identical to test.txt on the right.

In the current sync tool, test.txt on the left matches test.txt on the right, so the newer one will be marked for copying to the left (as well as the backup file).

With your proposal, test.txt.bak on the left will match with test.txt on the right.

[JOUBE]

... then I'd be more than happy to rechristen

You can do it by your own: Download the english texts from here, change the texts you want within the downloaded files and store the changed files in the language folder of your tc installation:

...
https://plugins.ghisler.com/languages/wcmd_eng.zip

HTH

Joube

[georgeb]

It would always lead to mismatches. Example: Take a text editor which always stores the previous save as file.ext.bak
...
With your proposal, test.txt.bak on the left will match with test.txt on the right.

Yes, of course, and rightfully so! For reconciliation-purposes it is important (other than simply making both Dirs equal) that the user gets to decide what to do about altered and duplicate files.

But since the altered test.txt on the left would now be compared to the old version with the identical name on the right both files would now fall into the "Different"-category without any automated selection for copying-direction. Whereas the .bak-version would now be (correctly) deemed as "unique left". And since in my concept of a parallel reconciliation-tool the optional duplicates-search would only be performed between both (prima vista) "unique"-columns - there would actually be no duplicate identified either. So no inadequate (mis-)-match would occur between those two as anticipated either.

So I wouldn't call that a mismatch. Whereas the classic "SyncDirs"-tool would provide for quick (and dirty?) equalization of both sides - the reconciliation-tool would provide the user with the factual situation needed for reconciliation-decision-making. He would correctly be pointed to the fact that "test.txt" on both sides are now "Different" and that the altered version on the left would now (presumably) be bigger in size (after adding text by editing) and newer in file-date. Whereas the (obsolete?) .bak-version on the left would now stand as a singular, added file with no actual counterpart on the right. So it could be pre-selected for copying to the right (for the purpose of simpy making both sides equal) OR the user could rather decide to simply delete an obsolete backup-copy.

It turns out that "simpy making both sides equal" and "true consolidation of contents" are really different angles of dealing with 2 comparable data-structures and therefore would actually justify the use of 2 parallel tools depending on the primary purpose of the operation.

[georgeb]

]You can do it by your own: Download the english texts from here, change the texts you want within the downloaded files and store the changed files in the language folder of your tc installation:

I'm afraid you completely misunderstood. As already stated I'm by no means interested in semantics. What I have proposed is a new tool with enhanced CAPABILITIES - and certainly not changing any terminology for the same standard-operations.

My concession of "rechristening" the newly proposed tool is due to the fact that our cherished Author has pointed out some elements of collision between the purpose of classic "synchronization" and my emphasis on reconciling and consolidating comparable data-structures.

[JOUBE]

It turns out that "simpy making both sides equal" and "true consolidation of contents" are really different angles of dealing with 2 comparable data-structures and therefore would actually justify the use of 2 parallel tools depending on the primary purpose of the operation.

I'm afraid you completely misunderstood.

No, you are now suggesting the creation of a second, separate tool for your idea. Just do this in the suggestion forum. Since the sync tool remains as it is in the meantime, the only thing that bothers you is the name and you can change it - as described.

[georgeb]

No, you are now suggesting the creation of a second, separate tool for your idea. Just do this in the suggestion forum. Since the sync tool remains as it is in the meantime, the only thing that bothers you is the name and you can change it - as described

No, the NAME doesn't bother me at all! I really couldn't care less!

[georgeb]

It would always lead to mismatches. Example: Take a text editor which always stores the previous save as file.ext.bak

Perhaps I should add a short addendum to what I've stated before as there may well be a common misunderstanding about my proposal:

My proposed variant of the tool - dedicated only to reconsiliation and consolidation of two comparable data-structures -
WOULD ALWAYS WORK IN
1. "By Content"- and
2. "Ignore Date"-mode.

So for my variant of the tool the other modes (without observing content and regarding the file-date in order to prioritize newer file-versions for copying-direction) wouldn't even need to be there any longer. I would leave those two modes completely to the "Classic-version-of-SyncDirs" as they really serve a totally different purpose.