Keep relative paths (relative to current directory) in listbox of find files

[monarch-lfv]

When copying files from the Branch View, there is an checkbox in the dialog box (because there is a path in the address bar):

Code: Select all

Keep relative paths (relative to current directory)

When searching in a specific directory, you can list the found files and folders, but when copying from search results, there is no such checkbox (because the address bar is empty). Is it possible to add the same checkbox?

[Fla$her]

In this case, TC must first check that the search is not conducted on several drives and there is no "ev:" at the beginning of the search string.
That is, such information must be stored in memory to check the last search query.

[monarch-lfv]

Personally, I've never searched on the entire drive (or multiple drives). Usually, the search is started from one specific directory - it can be considered the initial one, and paths can be saved relative to it.
When searching on several disks, I suggest adding the initial folder with the drive letter when copying with this checkbox.

[Fla$her]

It will not work, since the search can be conducted in several folders of both one and several disks.

[monarch-lfv]

What is the problem with keeping the highest identical path in this case? I don't see a problem.
What is the fundamental difference from branch view? Give an example why it is not possible?

[Fla$her]

TC searches for name.ext in the following folders: C:\Test; C:\Test2\Test3; D:\Test; D:\Test2.
The following appears in the search results:

Code: Select all

C:\Test\name.ext
C:\Test\1\name.ext
C:\Test\2\name.ext
C:\Test\1\2\name.ext
C:\Test2\Test3\name.ext
C:\Test2\Test3\dir1\name.ext
C:\Test2\Test3\dir1\dir2\name.ext
C:\Test2\Test3\dir2\name.ext
D:\Test\name.ext
D:\Test\blabla\name.ext
D:\Test\bla\bla\name.ext
D:\Test\bla\bla\bla\name.ext
D:\Test2\blabla\name.ext

How do you propose to keep relative paths here if the cropping of the left side should be common to everyone?

[monarch-lfv]

For your example:

Code: Select all

..\C\Test\name.ext
..\C\Test\1\name.ext
..\C\Test\2\name.ext
..\C\Test\1\2\name.ext
..\C\Test2\Test3\name.ext
..\C\Test2\Test3\dir1\name.ext
..\C\Test2\Test3\dir1\dir2\name.ext
..\C\Test2\Test3\dir2\name.ext
..\D\Test\name.ext
..\D\Test\blabla\name.ext
..\D\Test\bla\bla\name.ext
..\D\Test\bla\bla\name.ext
..\D\Test\bla\bla\bla\name.ext
..\D\Test2\blabla\name.ext

But your example, I have never used in my life.

I usually start the search from one specific folder, for example: "C:\Test\"
result:

Code: Select all

C:\Test\1\name.ext
C:\Test\2\name.ext
C:\Test\1\2\name.ext

then copying with a checkbox will be like this:

Code: Select all

..\1\name.ext
..\2\name.ext
..\1\2\name.ext

[Fla$her]

For your example:

And what is the practical point of this?

But your example, I have never used in my life.

You must understand that the author will not adapt to your needs, but will take into account the full functionality of the program.

As I said, it is necessary to take into account the preliminary settings, because the author will not want to process the entire list displayed on the panel, because this can greatly slow down the start.

[monarch-lfv]

For your example - no use. But even in this case, later you can merge the contents of the folders "C\" and "D\".
Another example, let's say I'm looking with content specific TXT files in a hundred folders with a complex structure. I display the search results on the panel and I want to copy them while maintaining the structure. How would you do it in this case?
In any case, it is not the search process itself that will have to be processed, but its results, which always have the structure Disk:\path\file.
Exactly the same as with branch view.

[Horst.Epp]

As fla$her already said, TC is not designed for your special needs.
I often use searches which include results from many paths
not to forget global searches driven from Everything results.
I never needed the logic you suggest.
Let's wait what Christian thinks about it.

[Fla$her]

In any case, it is not the search process itself that will have to be processed, but its results, which always have the structure Disk:\path\file.

Christian really does not like this kind of retarders, so the probability of such a scenario is small.

[monarch-lfv]

I don't think these are my special needs. The example given is quite simple. Moreover, this functionality is already present in branch view.
Everything does not cover this need. It basically searches by filename. It is more difficult when the search is performed by content, especially not just text files, but for example PDF, docx, mp3, etc.
We are waiting for the author TC ))

[ghisler(Author)]

There is a plugin for that called TreeCopyPlus:
https://totalcmd.net/plugring/TreeCopyPlus.html
It is used like a packer (Alt+F5) but instead copies files.

[monarch-lfv]

2ghisler(Author)
I known about this Plugin. There is also another plugin - CopyTree.wcx (more recent). Thought it might be possible to add built-in functionality.
A checkbox in the copy dialog would be much more convenient.
Moreover, if there is an implementation by a plugin, then there is both logic and a need for this.
Maybe add a parameter to the cm_PackFiles command to include a plugin (in this case named CopyTree) for button on bar?

[JOUBE]

I known about this Plugin. There is also another plugin - CopyTree.wcx (more recent). Thought it might be possible to add built-in functionality.

I know both plugins and use them too, albeit reluctantly. And I always have a bad feeling when I have to trust the programming skills of an external tool in terms of security and reliability for this basic function of a file manager. And unfortunately I have to, because the TC offers these - as I already wrote - basic - function unfortunately not.

Most of the time I use the following workaround in important cases (and I do this so that I stay within the Tc routines):
- Search with Alt+F7 with the corresponding file mask in the selected path
- [Feed to listbox] of the found files
- Compress with Alt+F5 (zip) with relative paths
- Extract the pack.zip to the new location.

And it can't really be that, can it?

That's why I support it very much

+1

Joube