Wrong name passing to non-Unicode WDX in search results

[MVV]

When non-Unicode plugin is used, it seems that TC passes short DOS name to it when name contains characters from other codepage - and this allows to work with plugin, that's great!

But in search results panel (after 'feed to listbox') TC passes usual long names - and plugin doesn't work since OS can't find such names:

Image: http://img98.imageshack.us/img98/6664/55270141.png (here field HLNK_Index works only for normal name but not for Unicode names)

Workaraund - TC should pass to non-Unicode plugins names in short DOS format in search results panel like in usual panel.

E.g. you may test it with my NTLinks plugin - its field Obj_RealPath returns short name for files with Unicode names in normal panel and wrong full name in search results panel.

[ghisler(Author)]

I will check that, thanks!

[MVV]

Confirm that in TC 7.55pb2 non-Unicode WDX plugins may work with names like (TC now passes DOS name for such filenames):

Code: Select all

简体中文 (Simplified Chinese).txt

But still doesn't work with names like (TC still passes long names that are incompatible with system codepage):

Code: Select all

Čeština.txt
Espańol.txt
Français.txt
Slovenský.txt

(system codepage is 1251)
(all filenames generated from language names in TC language files)

Why TC can't just use in search panel same method as in normal panel to transform filenames passed to WDX plugins? In normal panel TC passes right names anyway.

[ghisler(Author)]

Sorry, I only tested it with Russian here. I will check your other names.

I cannot use the normal method because I don't have the DOS name for all the path parts here. Any of them can contain such characters.

[ghisler(Author)]

I can confirm the problem with accents which Windows converts to the non-accent counterpart instead of a ? character, e.g. Espańol.txt -> Espanol.txt .

[MVV]

Works fine with all test names from archive specified here in TC 7.55 pb3.

Non-unicode plugins in TC 7.50a and earlier show details for 3 files, in TC 7.55 pb1 - for 4 files (Chinese name works), in TC 7.55 - all 9. Thanks!

[ghisler(Author)]

Great, thanks!

[MVV]

BTW I found similar bug with file tooltips - non-unicode plugin's fields are not visible in tooltips at all.

E.g. I have defined template 'file' with custom fields 'Index: [=ntlinks.HLNK_Index] (copies: [=ntlinks.HLNK_Count])\nReal path: [=ntlinks.Obj_RealPath]\n'. If I use my latest version of NTLinks (which is Unicode) I see custom tooltip for all files from above-mentioned archive, but if I use previous version (1.0.0.56 which is non-Unicode), I see just system tooltips (w/o custom lines) for files with Chinese symbols or accents.
Hm-m, that's strange! I have two folders "E:\Temp\___\0\Test 2" and "E:\Temp\___\0\Test 2", each contains files from mentioned archive, files in both folders are hardlinks. And in folder "Test 1" TC shows right tooltip e.g. for file "Čeština.txt" (with file index and real path in 8.3) but in "Test 2" TC shows tooltip w/o extra fields for "Čeština.txt"!

Well, I found a reason - in "Test 2" folder there is no 8.3 names for files (they were created by NTFS Links from original files in "Test 1" renamed using counter - NTFS Links doesn't support Unicode - and then renamed back to Unicode names using MRT), so TC can't pass them to plugins. But it is strange that 8.3 names weren't created during rename...

[ghisler(Author)]

Of course if the file doesn't have an 8.3 name, it cannot be accessed by non-unicode plugins.

For example, if you set the language settings for non-Unicode programs to Russian, you may get Russian 8.3 names. Now when you swich it to English, you cannot access these files from non-Unicode functions because the 8.3 names are still using Russian characters...

[DrShark]

...renamed using counter - NTFS Links doesn't support Unicode - and then renamed back to Unicode names using MRT), so TC can't pass them to plugins. But it is strange that 8.3 names weren't created during rename...

So is there a bug (with non-creating 8.3 names on renaming) or not? If yes, where is the bug: in MRT/TC or in Windows?

[MVV]

So is there a bug (with non-creating 8.3 names on renaming) or not? If yes, where is the bug: in MRT/TC or in Windows?

I think MRT calls MoveFile to rename, so it's Windows. I don't know any way to tell OS to create short names.

[petermad]

I don't know any way to tell OS to create short names

Try:

Code: Select all

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] 
"NtfsDisable8dot3NameCreation"=dword:00000000

[MVV]

But if I disable it, I won't have new 8.3 names at all! But when I made test files, OS made that names, so 8.3 names are enabled.

[ghisler(Author)]

You don't disable it with that switch, you enable it (Disable=0). But the problem is that you may get 8.3 names containing Unicode characters from other codepage in some cases, which makes it impossible to access these files from ANSI-only plugins.