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

[georgeb]

In a recent discussion I have learned that TC via <F5>Copy cannot copy the data selected as a subtree together with their relative paths without a plugin (like "CopyTree") - BUT CAN DO SO in CopyBranch-mode <Ctrl>B via "Keep Relative Paths"-checkbox.

Also recently I ran into the problem of replicating the subtree-structure (together with relative paths) after performing a Duplicate-Files-Search by binary content <F2> and selection of the proper duplicates to keep (via Num+) to another drive or auxiliary Dir/folder.

As the relative paths are explicitly given directly behind the filenames after each pair/triple of duplicates found and thus must be known to TC at this time - I can see no good reason as to why <F5>Copy performed after the Duplicate-Files-Search (with the proper files selected) could not ALSO PROVIDE THAT "Keep Relative Paths"-checkbox as an option by default (and again without the use of a special plugin, like in <Ctrl>B-CopyBranch-mode). IMHO this would constitute a desirable expansion of the Duplicate-Files-Search-capabilities.

[georgeb]

Really? Not a single forum-support for that reasonable request?

[Horst.Epp]

Really? Not a single forum-support for that reasonable request?

And you think that all forum members have no other work to do
and should immediately respond to your post

[georgeb]

And you think that all forum members have no other work to do
and should immediately respond to your post

No, no, just as any reader sees fit. Nobody should feel coerced to support things she/he doesn't genuinely appreciate. I've just been wondering.

[Hacker]

georgeb,
I mean, it's a very specific request, I personally have never needed it, but I am not against it, it's just that the feature is not relevant to me (and I guess neither to other users).

Roman

[Dalai]

I agree with Hacker. You seem to be the first to request such a feature, or maybe I can't remember if someone suggested this or something similar in the past. I wouldn't mind if it's implemented but it's kind of a niche use case and I don't know how much work the implementation would be (only Ghisler can tell).

Regards
Dalai

[JOUBE]

Unlike Hacker and Dalai, I find the feature very useful and not a niche feature at all. Mainly because I don't want to leave this central function of a file manager (copying) to a plugin. That's why I always use some kind of workaround

However, I'm mainly interested in this in the normal copy dialog and: not releative path, but absolut (total) path. That's why I'm out here...

[Fla$her]

Really? Not a single forum-support for that reasonable request?

It seems to me that first you should actively participate in supporting other requests yourself, before you are surprised at the lack of reaction to your own.

Regarding the topic, I can point out the obvious thing — the implementation of the requested option is possible only if you specify one path in the "Search in:" field. If the paths are listed with ; or specified @c:\path\filelist.txt with different paths, then such an option loses its meaning.
You also need to take into account that the relative path can only be the working directory before the search is performed, and if you change the path manually, it becomes unclear relative to which path such a function should work on.
In addition, there is a problem with standalone search when you have access to file lists and change the current paths in them.

[georgeb]

georgeb,
I mean, it's a very specific request, I personally have never needed it, but I am not against it

Agreed, quite specific. But given the fact that in <Ctrl>B-Branch-view this option is standard for <F5> (with the reasoning that for this special mode all the relative paths are already known to TC and can be listed in a customn-column-view) it would figure that there should be an analogous option for the duplicate-file-search-result-window, too, as all the relative paths are automatically listed behind the pairs of found duplicates in this view-mode by standard, even without a special customn-column-view.

[georgeb]

and I don't know how much work the implementation would be (only Ghisler can tell).

Well, after all it has been YOU who pointed out to me that such an option is STANDARD for <F5> within the <Ctrll>B-branch-view-mode - which I haven't even been aware of. So I tend to assume that the workload to implement such a totally analogous feature should be minimal as all the relative paths are likewise known (and even automatically listed) in this view-mode, too, so possibly the exact same code could be used/invoked here as is used for the <F5>-standard-checkbox in <Ctrl>-B-branch-view-mode.

[georgeb]

However, I'm mainly interested in this in the normal copy dialog.

As I see it in the normal <F5>copy-dialog the feature in question is already (implicitly) there. As when some parent-directory is selected for copying the whole subtree beneath it will be copied by standard with all the relative path-structure contained therein. However in <Ctrl>B-branch-mode as well as in the duplicate-file-search-result-window this is "a totally different ballgame". But my point is: it is the very SAME different ballgame for both of the latter-mentioned view-modes. And if such an optional checkbox (Keep Relative Phaths) is standard in <Ctrl>B-branch-mode the same should be true for the duplicate-file-search-result-window.

[Fla$her]

But my point is: it is the very SAME different ballgame for both of the latter-mentioned view-modes. And if such an optional checkbox (Keep Relative Phaths) is standard in <Ctrl>B-branch-mode the same should be true for the duplicate-file-search-result-window.

I made it quite clear to you above why this is not the case.

[georgeb]

It seems to me that first you should actively participate in supporting other requests yourself, before you are surprised at the lack of reaction to your own.

Point taken! Although I've actively supported quite a number of proposals I did find useful in the past. Perhaps a search for my username AND "support ++" might be revealing here.

Regarding the topic, I can point out the obvious thing — the implementation of the requested option is possible only if you specify one path in the "Search in:" field. If the paths are listed with ; or specified @c:\path\filelist.txt with different paths, then such an option loses its meaning.
You also need to take into account that the relative path can only be the working directory before the search is performed, and if you change the path manually, it becomes unclear relative to which path such a function should work on.
In addition, there is a problem with standalone search when you have access to file lists and change the current paths in them.

I am afraid, I do not understand the problems/contradictions you seem to point to here. In the duplicate-files-find-result-window EVERY pair/triple of duplicates found HAS ALREADY GIVEN A SPECIFIC, QUALIFIED PATH-NAME listed behind the filename. It shoud therefore be easy to REPLICATE this very same (relative) paths-structure to another drive or below any given parent-directory (as pre-selected in the opposite TC-files-panel). Otherwise a plugin couldn't successfully perform the trick either. But I totally agree with @JOUBE here that basic copy-functionality should always be part of the native file-manager (TC) without relying on any special plugins.

[Fla$her]

Although I've actively supported quite a number of proposals I did find useful in the past. Perhaps a search for my username AND "support ++" might be revealing here.

That's exactly what I did before I wrote about it. With the word "support" and your nickname, only one topic of someone else's authorship was found here. And you have made your mark here in only 4 other people's topics. That's not what I'd call active support.

In the duplicate-files-find-result-window EVERY pair/triple of duplicates found HAS ALREADY GIVEN A SPECIFIC, QUALIFIED PATH-NAME listed behind the filename. It shoud therefore be easy to REPLICATE this very same (relative) paths-structure to another drive or below any given parent-directory (as pre-selected in the opposite TC-files-panel).

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?

Otherwise a plugin couldn't successfully perform the trick either.

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

[Dalai]

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.

Regards
Dalai