Split/Combine + hex search

[vkeu]

There are two things which prevent me from switching from other file manager to TC:

1) The inability to freely combine any files (just like in Altap Salamander or simple "copy /b ... + ... ..."). I don't want to name the files in the TC syntax just to be able to combine them.

2) The never ever (correctly) working hex search. The results either include false positives or don't include real hits. The first bug may be connected to the translation of the hex search string which is (also) interpreted as text (thus creating false positives). Moreover, hex searches like "\x00{10,}" don't work, while searching for "00000000000000000000" as hex works.

I believe these should be fixed since otherwise TC is a great product (IMHO the best in its class)

[Hacker]

Hi vkeu,

freely combine any files (just like in Altap Salamander or simple "copy /b ... + ... ..."). I don't want to name the files in the TC syntax just to be able to combine them

Well, you'd have to use some simple script for that.

The never ever (correctly) working hex search.

Enable "Case sensitive". TC's hex search translates the hex string to text before searching (so that hex and normal text search can be used in one search field) and if you don't enable "Case sensitive" TC finds also the other case matches.

HTH
Roman

[Dalai]

1) The inability to freely combine any files (just like in Altap Salamander or simple "copy /b ... + ... ...").

You can freely combine any files, just not with the item in the menu. Copy file A to file B and select "Append" in the Overwrite prompt. Yes, this might be tedious for a lot of files, but (almost) everything can be solved with a script when TC provides the parameters for it.

The never ever (correctly) working hex search. The results either include false positives or don't include real hits.

Please provide examples. Otherwise it's just crystal ball type of stuff. However, it has been explained several times in the forum that hex search doesn't search case-sensitive, i.e. it finds lowercase and uppercase characters, even if the term only contains one of them.

Moreover, hex searches like "\x00{10,}" don't work, while searching for "00000000000000000000" as hex works.

Yeah, well, the former is a RegEx, so it's no wonder it doesn't work. It's a TC limitation that it can't search for hex strings and RegEx (text) at the same time. You're free to make a suggestion in the Suggestions sub-forum (although I'm pretty sure it's already been suggested to remove this limitation).

Regards
Dalai

[vkeu]

Thank you for your replies.

1) The problem is not only limited to Combine but also to Split. Nobody wants to use complicated workarounds if a simple solution is at hand (e.g. Altap Salamander).

2) I consider both search-related issues a bug. When I search for an exact hex pattern I don't want to see any other (irrelevant) results. I believe both issues (incl. RegEx) could be solved if text search could be deactivated when searching for hex (e.g. WinHex has a "Direct byte-wise translation for GREP" option for this purpose which simply means no transformation at all).

[ghisler(Author)]

1) There is a reason why this isn't supported: People will just try to combine files which do NOT work when simply appended to each other, like
- ZIP archives
- AVI movies
- DOC/DOCX/XLS/XLSX documents
- PDF files
etc. etc.
The combine function is only meant to be used to combine files which were previously split with Total Commander or any other tools creating numbered parts.

2) As Hacker has pointed out, hex search considers options like "Case senstitive". Why? It allows to make searches like
"PK" 01 02
which is then converted to a string before searching.

[vkeu]

1) Denying useful features to more advanced users just because of some dummies? There many other, easier ways a user can damage a file, even in TC.

2) Still the hex searches do not work which makes TC unusable for even only a little advanced users again

[Dalai]

2) Still the hex searches do not work which makes TC unusable for even only a little advanced users again

You still haven't provided concrete examples for this claim. The case-sensitivity was already pointed out, but this reads like there's more to it. If there is, please back it with examples. If there isn't, well ...

Regards
Dalai

[vkeu]

Oh yes I did:

hex searches like "\x00{10,}" don't work, while searching for "00000000000000000000" as hex works

You even confirmed:

it's no wonder it doesn't work. It's a TC limitation

[Dalai]

Well, this example doesn't work (and I explained why), but your claim is still wrong, because hex search works fine - within the TC limits that is. Every software has its limitations. To say that some feature doesn't work at all* when it indeed does, is ... quite bold to say the least.

*) How else could/should the wording "The never ever (correctly) working hex search" interpreted if not like this?

Regards
Dalai

[vkeu]

*) That I can never rely on it.

I often receive false positives (sought and "found" patterns are not present in the files when cross-checked in WinHex). I don't have a real example at hand at the moment; as soon as I do, I will post it here (may take some time).

I still believe the fix should be easy and, above all, helpful (to others as well). This applies to both issues.

[gdpr deleted 6]

With regard to "\x00{10,}". Please stop calling it a hex search. It is not.

It is a regular expression. In other words, in the search dialog, hex search should be turned off, and regex should be turned on.

Generally, TC handles such regular expressions of such structure already. But, and it's a big BUT, here TC's regex engine has indeed a limitation, as it does not support the NUL character \x00 in a regular expression.

I kinda agree as well as disagree with it being a limitation contrary to being a bug. \x00 being unsupported is a limitatio0n. But the response of the search function is not really helpful and misleading. The response of the search function to a regex pattern containing \x00 is either non-action or a misleading error dialog, which i would consider a bug.

After having now looked for and having seen several forum threads where people stumbled about the \x00, \x0000 issue, i just made a suggestion to either improve TC's response to regex pattern containing unsupported \x00 or augment the regex help about the unsupported NUL char.