Copy files with their relative path-structure after duplicate-files-search

[georgeb]

Again, the paths of each duplicate file may not match anywhere at all, so they won't have a shared directory against which to replay the chain in the target folder. All that could be done in this case is to reproduce the entire chain, starting with the drive letter. But who needs this?

May not match anywhere? Match to what, that is? And yes, if necessary to hold those structures unequivocally apart, then the entire chain is exactly what I'm talking about. And, ehm, I would need this - hence my proposal here. The only difficulty of that kind as mentioned by you would occur if the duplicates are found on/between different drives. So how to represent different drives below some local (auxiliary) parent-directory? Even that wouldn't be "rocket science". Just substitute "C:\", D:\ etc. against "Drive_C\", "Drive_D\" and so forth - and Voilà! We're good to go!

The plugin has a level selection, which the TC copy dialog does not provide.

If the plugin can provide that - I would absolutely not object to standard-TC showing that same enhanced capability. As @JOUBE has already stated standard file-operations like copying should IMHO always be part of basic file-manager-capabilities without relying on any 3rd-party-accessories.

[georgeb]

The thing is that a search - regardless of whether or not a search for duplicates is performed - can be made across different directories, volumes or even multiple networked systems. The results can be located in entirely different directories and/or structures. Which of these paths should be kept? All of them or just some of them? And to what directory level? The existing plugins have answers to these questions (leaving it to the user to decide), but TC's function is very basic or even minimalistic.

Just to be clear, I'm not against implementing a feature like this, but IMO the questions should be considered and discussed (and answered eventually) before actually expanding the feature to search results.

I totally agree to all you've said. But all of these different structures/drives could be relatively easily substituted (and referred to) by local designators (like already mentioned "C:\" by "Drive_C\" and so on). And which paths to keep? In case of doubt I would say "all of them". But a user-configured level-selection (as provided by the plugins) would be a fine addition to standard-TC, too, as we probably can all agree that TC's overall and general functionality can by no means - and should not - be seen as anywhere NEAR to "basic" or even "minimalistic" since a very long time ago. It has clearly evolved into the most capable "power-tool" available out there!

[Dalai]

[...] TC's overall and general functionality can by no means - and should not - be seen as anywhere NEAR to "basic" or even "minimalistic" since a very long time ago.

I was just referring to the existing "Keep relative paths" checkbox in the copy dialog when called from branch view. This is just an on/off switch, nothing more and thus very basic.

It has clearly evolved into the most capable "power-tool" available out there!

Indeed.

[georgeb]

This is just an on/off switch, nothing more and thus very basic.

Well, if properly implemented (defaulting to the entire path-structure) a simple on/off-checkbox would be all that's needed in the analogous situation of the duplicate-files-search-result-window, too.

[Fla$her]

May not match anywhere? Match to what, that is?

C:\dir1\dir2\name.ext
D:\folder1\folder2\name.ext
As you can see, there are no matches in the base directory.

And yes, if necessary to hold those structures unequivocally apart, then the entire chain is exactly what I'm talking about.

Where did you write about the entire chain?

And, ehm, I would need this - hence my proposal here.

For me, there is no practical benefit in such a chain. Outside of plugin testing, I've never resorted to this anywhere.

The only difficulty of that kind as mentioned by you would occur if the duplicates are found on/between different drives. So how to represent different drives below some local (auxiliary) parent-directory? Even that wouldn't be "rocket science". Just substitute "C:\", D:\ etc. against "Drive_C\", "Drive_D\" and so forth - and Voilà! We're good to go!

I think that's what we're talking about. Only such replacements are unlikely to be approved, so I immediately wrote about the drive letters that the plugin uses to name the first folders (analogous to %B+0 in the button parameters).

The whole point is that in the mode of displaying files to the panel after searching, the parent directory is the directory of another panel, i.e. the search tool was not initially focused on the base directory, given the ability to search on different drives.
Why am I writing about the base directory, and not about all the parent directories for each found object?
Precisely because a piecemeal search will greatly slow down the parsing of the list to determine common directories and groupings when copying.
For DirBranch mode, it's enough to remove the common left part in the list to get a list of relative paths, which is a quick processing, unlike what is needed for the found list. Personally, I don't mind this approach, but given Christian's pedantic attitude to the speed of performing simple functions, the results of the appearance of such functionality can only be guessed.. By the way, all this has already been discussed in this thread, where the author limited himself to pointing out the plugin.

[georgeb]

C:\dir1\dir2\name.ext
D:\folder1\folder2\name.ext
As you can see, there are no matches in the base directory.

Again, who needs matches in the base directory? Both paths start with a drive-letter and thus are unique as well as unambigous. My goal has always been to generate auxiliary-copies of (only) the duplicates found, albeit separated by source-path and/or after individual/group-wise de-/-selection. So in a simple case where one group of duplicates is always found on drive C:\ and the other group always on drive D:\, albeit possibly in different locations of different substructures, then all I want are 2 separate copies, one of both drive-substructures each. So that later on I can individually decide within the conventional TC-panels which side has the correct/better/newer substructure which therefore should prevail on both sides in the future for the purpose of consolidation where only few intentional duplicates would survive but for the major part only one version thereof would prevail - albeit only the one located in the proper location with the correct name (in other words getting rid of misspelled/falsely-renamed and/or copies wrongfully moved to incorrect locations).

Where did you write about the entire chain?

That was implicitly clear from the beginning as I've always been referring to the complete paths as they are given right behind each duplicate listed in the search-result-window. All of these paths always start with a drive letter - be it the same after a search only within one drive or be it different ones in case of a multiple-drive-duplicates-search.

I think that's what we're talking about. Only such replacements are unlikely to be approved, so I immediately wrote about the drive letters that the plugin uses to name the first folders (analogous to %B+0 in the button parameters).

Who the hell would have to "approve" something here? I mean "Drive_D" (For D:\) for example is absolutely self-explanatory as it couldn't be any clearer for Heaven's sake

The whole point is that in the mode of displaying files to the panel after searching, the parent directory is the directory of another panel, i.e. the search tool was not initially focused on the base directory, given the ability to search on different drives.
Why am I writing about the base directory, and not about all the parent directories for each found object?
Precisely because a piecemeal search will greatly slow down the parsing of the list to determine common directories and groupings when copying.

Who would even need parsing here - or care much about "base-directories"? Just use the explicit AND complete path as already given adjacent to each duplicate found in the duplicate-search-result-window. It's ready-made for being used as is!

[Fla$her]

Again, who needs matches in the base directory?

Someone who understands the principle of relativity correctly.
Relative to what should the chain appear? Relative to emptiness? This is stupid from the point of view of logic.
Otherwise, this will be called differently than the relative path.

So that later on I can individually decide within the conventional TC-panels which side has the correct/better/newer substructure which therefore should prevail on both sides in the future for the purpose of consolidation where only few intentional duplicates would survive but for the major part only one version thereof would prevail - albeit only the one located in the proper location with the correct name (in other words getting rid of misspelled/falsely-renamed and/or copies wrongfully moved to incorrect locations).

Explain more simply (better with working examples). My brain broke down trying to understand the described approach.

That was implicitly clear from the beginning as I've always been referring to the complete paths as they are given right behind each duplicate listed in the search-result-window. All of these paths always start with a drive letter - be it the same after a search only within one drive or be it different ones in case of a multiple-drive-duplicates-search.

Specifying full paths doesn't answer the question of the resulting chain, so it wasn't obvious.

Who the hell would have to "approve" something here?

The author of the program and no one else. This follows from my context.

I mean "Drive_D" (For D:\) for example is absolutely self-explanatory as it couldn't be any clearer for Heaven's sake

It doesn't matter what you think about it. It's important that there is no need for prefixes like 'Drive_'. Don't freak out in vain.

Who would even need parsing here - or care much about "base-directories"? Just use the explicit AND complete path as already given adjacent to each duplicate found in the duplicate-search-result-window. It's ready-made for being used as is!

Have you ever developed something like this? At least at the scenario level? I'm afraid not.
Take NTLinksMaker as an example. There, right in the dialog, the path to the base directory is indicated, relative to which the structure can be reproduced. Copying TC from DirBrach mode (Ctrl+B) works similarly.
If the current directory is C:\Dir, then it becomes the base for the remainder of the path chains:
C:\Dir\file.ext
C:\Dir\Dir2\file.ext
C:\Dir\Dir2\Dir3\file.ext
By deleting C:\Dir\, in the remainder, the paths that will be reproduced are obtained.

And a single complete path doesn't provide any information at all to form a relative path. It only provides information for reproduction the entire chain, including the drive letters, as I wrote earlier.
Why is it easier with a plugin in this regard? Because by setting the nesting level, you can cut off the left part, dividing the path components by backslash. But there is one significant problem with this custom relativity — the number of components in some paths may be less than the user specified, which will be an error. This human factor will also be taken into account by the author when considering the option with levels. Only the zero level, as, in fact, indicated in the plugin's readme, is safe. I advise you to read the description of the DefaultCopyLevel key in order to evaluate the full depth of the optionality.

[georgeb]

Someone who understands the principle of relativity correctly.
Relative to what should the chain appear? Relative to emptiness? This is stupid from the point of view of logic.
Otherwise, this will be called differently than the relative path.

Ok, so probably my bad then. As I perhaps shouldn't have over-emphasized the (RELATIVE) path-structure in my request. On second thought ABSOLUTE paths will do - as ready-made and given adjacent to each duplicate file-pair in the <Alt>F7-duplicate-files-search-result-window.

The author of the program and no one else. This follows from my context.

That is understood. So I have no objections whatsoever if Christian would decide to go for different designators as "Drive_C", albeit some unique designator would have to be invented here as drive-letters like C:\ can obviously not be part of a conventional directory-chain already residing below some local parent-Dir on any given drive.

It doesn't matter what you think about it. It's important that there is no need for prefixes like 'Drive_'. Don't freak out in vain.

Freak out? Why should I? I'm open to any suggestion about how to represent/replicate a full path (obviously starting with a drive-letter) below any local (auxiliary-) parent-Dir that already resides on a given (different?) drive, in an unambigous way, that is.

[Fla$her]

On second thought ABSOLUTE paths will do - as ready-made and given adjacent to each duplicate file-pair in the <Alt>F7-duplicate-files-search-result-window.

Which pair (there can be any number of duplicates)? What are you about? The path is shown to the right of each file name. No paths for the "pair" are displayed, and in the absence of a common chain, they in fact couldn't be.

albeit some unique designator would have to be invented here as drive-letters like C:\ can obviously not be part of a conventional directory-chain

You're confusing. C:\ is the root drive folder. С: is the drive name/path, but C is the drive letter that I wrote about, referencing CopyTree and %B+0 (Have you at least checked it out?).

Freak out? Why should I?

Well, I attribute such statements as "Who the hell would", "for Heaven's sake" and so on to the expression of excessive emotions. )

I'm open to any suggestion about how ...

I have already written how. As in CopyTree.

[georgeb]

Which pair (there can be any number of duplicates)? What are you about? The path is shown to the right of each file name. No paths for the "pair" are displayed, and in the absence of a common chain, they in fact couldn't be.

Yes, there can be any number. And EACH of them has a qualified path listed adjacent to each filename. Now ONLY IF SELECTED - ALL OF THE SELECTED FILES (among the totality of duplicates found) can be replicated exactly to its initial, well-known path-structure as to be re-established below some common parent-Dir (like "AUX\Drive_D\", which you obviously didn't like, but you're free to propose a better name-substitute for the drive, without the colon, that is).

You're confusing. C:\ is the root drive folder. С: is the drive name/path, but C is the drive letter that I wrote about, referencing CopyTree and %B+0 (Have you at least checked it out?).

No, not interested in all your smart-alec bickering. I think I've made my point abundantly clear.

[Fla$her]

ALL OF THE SELECTED FILES (among the totality of duplicates found) can be replicated exactly to its initial, well-known path-structure as to be re-established below some common parent-Dir

As we've already established, in the case of different drives, there will be no common directory.
In this case, I strongly recommend that you change the title of the topic and the description in the first post so that people do not have the illusion of what you want. Remove the text about relativity from the description and write directly about the reproduction of the entire chain. Then we'll see who wants to support it.

No, not interested in all your smart-alec bickering.

Trying to distort the meaning of my words about the drive letter is what I call inappropriate bickering.
Regardless of your interest, I consider it my duty to respond to that.

[georgeb]

As we've already established, in the case of different drives, there will be no common directory.

WE have established absolutely nothing here. As of course there can be a common - local - parent-Dir. Contrary to your liking it could (for example) be:
"AUX\Drive_D\<substructure_of_all_selected_duplicates_found_on_ Drive_D>"
"AUX\Drive_E\<substructure_of_all_selected_duplicates_found_on_ Drive_E>"
"AUX\Drive_F\<substructure_of_all_selected_duplicates_found_on_ Drive_F>"
.
.
"AUX\Network-Resource1\..."
"AUX\Network-Resource2\..."
=> Then "AUX" is obviously it, the common, much-sought-after local-parent-Dir for the whole structure.

Trying to distort the meaning of my words about the drive letter is what I call inappropriate bickering.
Regardless of your interest, I consider it my duty to respond to that.

Always feel free to do so, it's a Free Country we live in.

[Dalai]

2georgeb
Just FYI: AUX is a reserved name in Windows. See https://ss64.com/nt/syntax-filenames.html#reserved

[Fla$her]

WE have established absolutely nothing here. As of course there can be a common - local - parent-Dir. Contrary to your liking it could (for example) be:

Which folder you want to copy the structures to is solely your preference and no one else's.
This has nothing to do with the common source folder we were talking about.

Always feel free to do so, it's a Free Country we live in.

I don't understand which country can be discussed on an international resource...

[georgeb]

Just FYI: AUX is a reserved name in Windows. See https://ss64.com/nt/syntax-filenames.html#reserved

My bad. Be it "AUX1" then. Or even "LCFFJFDH".