OffTopic / Tool to display FILE*NAME* as raw entry from the MFT

[milo1012]

Isn't is easier to use cm_SaveSelectionToFileW instead and open the resulting file in a Hex editor (or even Lister in Hex mode)?

Yes, that's even simpler

[white]

• just mark your files, now use TC command "cm_CopyNamesToClip" or e.g. the button "Copy names with full path" already shipped with TC

TC comes also shipped with a menu. The menu option Mark contains the option Copy Selected Names to Clipboard.

• use a decent text editor...

Since the described goal is to "reveal any actual differences that might exist in notation/encoding/symbols used within those names", it seems more convenient to me to paste the filename in a unicode analyzer, for example: https://www.fontspace.com/unicode/analyzer

[georgeb]

Thanks a lot guys, @Dalai, @milo1012, @White for your continued advice. I think we're now on the same page in terms of a feasible, simple solution. Here I run "UltraEdit" which of course has all the "bells and whistles" necessary to implement your advice. Creating UTF-16LE_no_BOM was a breeze, names pasted from TC and viewed in HEX - and here we go. I can confirm that I've now been able to reveal those sought-after native bytes of the true filename by applying "out-of-the-box", in-house-means only.

TC already uses something like this if not exactly this function to retrieve the filenames. You don't need to do any coding.

Could you please elaborate on that again? The method via pasting the names from TC to a decent editor and HEX-viewing them from there is plain and simple as well as successful but unfortunately the results thereafter cannot easily be re-integrated into a TC-view.

Hence the end-goal would still be to create a custom-column-view-mode, much like you've already suggested, which could directly display those native HEX-strings representing the true file-name in an additional, extended custom-column within a full-page-TC-panel.

[Dalai]

Could you please elaborate on that again?

The reference to the FindFirstFile(W) function was made to explain and demonstrate that it's not necessary to consult the MFT to get the information you seek.

[...] but unfortunately the results thereafter cannot easily be re-integrated into a TC-view.

Well, it looks like you didn't try the plugins I and milo1012 suggested, so ...

Regards
Dalai

[georgeb]

Well, it looks like you didn't try the plugins I and milo1012 suggested, so ...

i already promised to look into these but it will take some more time as I've been busy testing and implementing earlier suggestions until now as also implementing my own findings like "buttonizing" ActiveDiskEditor within TC. The plugins are already downloaded but before messing around with them I would have preferred to see some more elaborate documentation about their proper usage but so far have been unsuccessful to find some. But I promise to keep looking and trying.

[Dalai]

The plugins are already downloaded but before messing around with them I would have preferred to see some more elaborate documentation about their proper usage but so far have been unsuccessful to find some.

Well, I assumed you already know how to use Content plugins. The TC Wiki might be a good starting point: https://www.ghisler.ch/wiki/index.php?title=Content_plugin

Regards
Dalai

[georgeb]

Well, I assumed you already know how to use Content plugins. The TC Wiki might be a good starting point: https://www.ghisler.ch/wiki/index.php?title=Content_plugin

You've been correct in your initial assumption that I am familiar with using content plugins. And I've performed initial tests with both plugins so far. That way I've been able to create various custom-column-modes that would tell me e.g. if the filename is Unicode or ANSI, if write-access is possible or if the filename is NFC-compliant, yes or no, and what the NFC-compliant name would look like - again in conventional font-representation (and again looking completely identical to the composite-symbols-version of the filename).

But that is all still miles away from showing the name in HEX-representation as desired - or even from somehow re-importing the HEX-representation delivered by the editor when viewing the "cm_SaveSelectionToFileW"-created list of filenames. That is round about the current state of progress.

[Dalai]

If these are the only Unicode names you can come across, i.e. there are no other cases for such names, then these plugins help nonetheless. You don't need to see the filename in any other representation. Use UnicodeTest (in a search) to find them, then use NFCname in MRT to rename them (or use the latter for both).

Regards
Dalai

[georgeb]

If these are the only Unicode names you can come across, i.e. there are no other cases for such names, then these plugins help nonetheless. You don't need to see the filename in any other representation. Use UnicodeTest (in a search) to find them, then use NFCname in MRT to rename them (or use the latter for both).

The NFC_yes_or_no-answer is practically already provided by @tuska's idea of color-coding such filenames without even having to switch the view-mode. But call me an old-fashioned guy - before I would start any re-naming- or normalization-process I would still prefer having an option to VISUALIZE those actually different names in a representation (any representation, needn't necessarily be HEX) indeed enabling me to SEE THE TRUE DIFFERENCE between otherwise indistinguishable filename-versions beforehand. And ideally this should happen within the TC-file-panels, possibly by applying some custom-columns-mode as you've already suggested.

Also because both plugins are now between more than 6 and 10 years old I'm in doubt if it would still be preferable to use any of those together with the MRT for the subsequent normalizing-/re-naming-process or if they might somehow negatively interfere with MRT's in the meantime implemented INTERNAL normalization-method using the [​u][N]-option.