Total Commander

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.

Why? Windows isn't case sensitive.

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:

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

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.

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.

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

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

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

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.

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

No, USERNAME contains just account name as it should, but TEMP expands to a path with doubled backslash in it. And since TC uses temp folder for its temporary files, these files have paths with this doubled backslash.

Just tried it with TC 11.01, problem still exists.
Steps to reproduce:
1. Open cmd.exe and set TEMP and TMP to a path with doubled backslash, in my case it is C:\temp\USERNA~1\\7.
2. Start TC from that console to make it inherit this non-normalized path to temp folder.
3. Open a .tar.gz file, then enter .tar in it, try viewing any file in .tar.
4. Even for a .txt file (that doesn't require any plugins) I get "Access denied" error with path to that file in temp folder with non-normalized path.
5. Without closing error message on step 4 I see that temp folder only contains .tar file, but there is no file that I tried to view.

2MVV

On my corporate machine I have TEMP set to C:\temp\%USERNAME%\

Can't you just set temp to C:\temp\%USERNAME% instead of C:\temp\%USERNAME%\ - or is that out of your hands on that machine?

Normally environment variables for paths are not set with a trailing backslash.

As for me, I can just define path to TC temp dir in Autorun's cfg file, but I think that this little TC issue should be resolved since it may broke many TC features in case of incorrectly configured environment, and it is pretty easy to resolve. Though non-normalized paths in Windows shouldn't cause any errors at all, any system API function accepts such paths w/o any troubles, so TC should also live fine with them.

MVV wrote: ↑2023-12-14, 09:57 UTC... in case of incorrectly configured environment ...

So, no support for this suggestion. -1