[9.21a] Cd doesn't normalize paths

[MVV]

When I do cd D:\\DirA\\DirB\\DirC\\DirD, TC opens dir and shows this non-normalized path in path bar, and also passes it to plugins etc, causing errors in plugins. E.g. when I press F3 in a file after such cd, it applies NoDirQuickView plugin for file (but this plugin is only for folders).

Please make TC normalize paths passed to cd command or command line or corresponding WM_COPYDATA message.

[ghisler(Author)]

Why? Windows isn't case sensitive.

[MVV]

I mean that you should normalize (canonicalize) external paths (that come to cd command etc) by removing duplicate backslashes or stuff like \.\ or \..\, just like GetFullPathName function does before changing dir or displaying them in path bars:

Code: Select all

wchar_t buf[260];
GetFullPathName(L"D:\\\\\\dir1\\\\dir2\\\\..\\\\dir2_again\\.\\dir3", MAX_PATH, buf, nullptr);
// --> L"D:\\dir1\\dir2_again\\dir3"
GetFullPathName(L"\\\\comp11\\D\\\\\\dir1\\\\dir2\\\\..\\\\dir2_again\\.\\dir3", MAX_PATH, buf, nullptr);
// --> L"\\\\comp11\\D\\dir1\\dir2_again\\dir3"

[ghisler(Author)]

If I remember correctly, GetFullPathName only fixes the last name part after the last backslash, but not the other parts of the path.

[MVV]

As you can see, it fixes overall path, so it may be quite useful here. It doesn't check if final path exists so it only canonicalizes it. It would be very nice to see this fixed because sometimes I need to copy paths from IDEs where slashes in strings are usually doubled.

[MVV]

Maybe it is time to fix this? Today I wondered why no file properties shown on Alt+Enter and why context menu looks so trimmed, then I've noticed an extra backslash in the path.

Very often such problems are from concatenating environment variables with trailing backslashes with some subpaths. Such paths are supported by OS and shouldn't cause any problems in TC too. You can either normalize paths like CMD.EXE does (try to execute cd /D %SystemRoot%\\System32 command, you'll see normalized current path without extra backslash) or just properly handle non-normalized path (i.e. extra backslashes shouldn't affect on TC/plugins functionality). But current behaviour is buggy: TC shows valid folder contents but some functions are broken.

[ghisler(Author)]

Removing duplicate slashes is easy, so I will add that. However, I will not normalize upper-/lowercase, because Windows is case insensitive.

[MVV]

Thanks, I think you can juse use GetFullPathName, it fixes extra backslashes or references to . or .., but keeps cases.

[ghisler(Author)]

I'm already remoning \..\ and \.\ etc, all I need to do is remove \\ and //.

[MVV]

BTW I found a real problem caused by this issue. On my corporate machine I have TEMP set to C:\temp\%USERNAME%\ and there is something (probably security setting) that appends a numeric subfolder name, and it appends it with extra backslash, resulting in TEMP variable value like C:\temp\%USERNAME%\\107. This causes TC to fail when I try viewing or extracting files fron a nested archive because it gets a doubled backslash in its path when it is extracted by TC to the temporary folder and opened.

[ghisler(Author)]

Could you explain in more detail what happens? Does %USERNAME% contain something like MVV\\107 or do I misunderstand that?