Sep. tree: dir not selected in it if 8.3 names in panel path

[DrShark]

If some name in panel path contains a 8.3 shortname - as it seen in panel address field, panel directory is not selected in Separate tree.
Instead, in the tree Desktop is selected.

Maybe other Tree modes are affected too, didn't tested yet.

[petermad]

Hmm, I cannot reproduce that - you may have to explain step by step what you do

[DrShark]

step by step what you do

1. Create path:
c:\USERNAMER\AppData\Local\Temp\
2. In left panel, via Shift+F6 and address bar, or CD in command line, go to:
c:\USERNA~1\AppData\Local\Temp\
3. In right panel, the same way go to:
c:\USERNAMER\AppData\Local\Temp\
4. Activate two Separate trees, if not active.
Left panel tree will have focus on Desktop, here's wrong behaviour.
Right panel tree will be focused on Temp dir.

[petermad]

With this description I can confirm your report. IMHO I should definately not behave this way.

[milo1012]

Why do you construct such a weird path, reminding one of the actual user profile?
A single long (> 8 characters) dir name anywhere is enough.

Now, I wouldn't call it a real bug, because of the viewing mode of file names:
If you switched off long names, i.e. enabled 8.3 names (via Configuration -> Display -> Use long filenames ,
or cm_Switch83Names), the focus will be set correctly.
So if you forcefully enter a 8.3 path while you enabled long filenames, TC will probably not enter the compatibility layer,
and tries to resolve a path with a mixture of 8.3 names and non 8.3 names, which will fail.
So IMO it's the user's responsibility.
But sure, fixing it can't hurt.

And BTW, you can switch off creation of 8.3 names on NTFS AFAIK, so TC wouldn't be able to enter it anyway then.

[DrShark]

Why do you construct such a weird path, reminding one of the actual user profile?

Real path at time I first encountered a bug was different, the case was with pasting it from other program to TC. My example posted above is just looks similar and made only for testing purposes.

About your arguments regarding swithing on/off 8.3 names display in TC and NTFS. The tree is the element for navigation purpose. If I past in TC panel a path with 8.3 name from other program, belonging panel's Tree should navigate to panel's folder and not somewhere on desktop - that's what I expect. And of course if 8.3 names disabled on NTFS, Windows will not resolve the path with them and it will not be a TC bug.

And following close to your logic in which current TC behaviour is correct, Tree should navigate to Desktop when in panel user goes to Junction, Folder Symlink or Folder shortcut. From some point, strictly technically, it may be correct, but it breaks user experience.

So IMO it's the user's responsibility.

Average user may not even know the difference between long name and short name. Total Commander is not a tool made only for IT professionals.

[milo1012]

Average user may not even know the difference between long name and short name. Total Commander is not a tool made only for IT professionals.

I'd say the "average" user nowadays doesn't know much or anything at all about 8.3 names.
So the chance that he manually types such path is thin.
Like I said, I'm all for fixing this behavior, but the actual impact you describe for the average user is a bit far fetched IMO.

And of course if 8.3 names disabled on NTFS, Windows will not resolve the path with them and it will not be a TC bug.

Obviously.
I just wanted to express that support for 8.3 names is getting less common
( https://www.google.com/search?q=8.3+name+creation+disabled )
and so the impact of the bug is even smaller.

[ghisler(Author)]

Currently it's not planned to convert all path parts from short to long names just for showing them in the tree, this would be too slow with some drives (mainly network drives).

[DrShark]

Currently it's not planned to convert all path parts from short to long names just for showing them in the tree, this would be too slow with some drives (mainly network drives).

Very sad to hear that. Because in "copy-paste from other software" case I will have to waste even more time converting such path manually before pasting it to TC, or even more time pasting it "as is" and then going through all the three from Desktop item to my folder in panel.

If it is so slow on network drives, why not have it by disabled by default for them? Or even disabled at all with possibility to enable for certain drives or types of them (local/removable/network)? IIRC TC already have "compatibility" settings for USB drives designed in similar way.

Indeed, without getting this fixed, all my separate tree-related suggestions that I'm currently posting to make them good enough for using on daily basis are useless.

[DrShark]

The above behaviour is not changed in 9.0, but since the topic is still in "Bug reports" forum I still have a hope for a fix.

Also I have some new suggestions about possible fix:
1. I noticed that the bug affects regular tree too, but this tree behave different:
if in file panel opposite to a regular tree in the address bar or in command line (using cd command) to go to path c:\Users\USERNA~1\AppData\Local\Temp\
regular tree will focus c:\Users\
This behaviour seems better than current one of Separate tree which focuses on Desktop. If conversion of all path parts from short to long names is not acceptable, maybe at least it's possible to make Separate tree behaviour on focusing the same like in regular tree?
2. On conversion of all path parts from short to long names. Could it be a good compromise to use this conversion ONLY if tree (separate or regular) is opened AND user inserts the path in the address bar or command line after cd command (to make the conversion after user inserted path and pressed Enter in address bar or command line)?

[DrShark]

2ghisler(Author)
In email you wrote that for trees "TC calls FindFirstFileEx now which does not return the 8.3 names with the used parameters." You also wrote that it's possible to convert a path with 8.3 names to a path with long names, and then pass converted path to FindFirstFileEx, although "it would be much slower because it would have to be called for every single directory". Well, I'm OK with slower tree expanding, so why not implement it disabled by default?