Wrong contents of context menu if path contains double

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: white, Hacker, petermad, Stefan2

Post Reply
serg_joker
Junior Member
Junior Member
Posts: 18
Joined: 2009-08-27, 14:51 UTC

Wrong contents of context menu if path contains double

Post by *serg_joker »

Hi, here is minor bug, we've found it apparently.

1. Create folder like c:\dir1\dir2\dir3
2. in command line enter "cd c:\dir1\\dir2" (double backslash in the path)

After that pat field will contain "c:\dir1\\dir2", however it's more correct to change the path to "c:\dir1\dir2" i.e. normalize the path removing unnecessary repeating backslashes. BTW, if we try to use command like "cd c:\dir1\..\dir1\dir2", resulting path (correctly) is "c:\dir1\dir2" i.e. unnecessary part is deleted correctly.

3. Try to call context menu on dir3. Context menu must contain both total commander specific items and Explorer items. But, if path contains doublebackslash, context menu does not contain explorer items.

Regards,
Sergey.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Confirmed.
User avatar
silencer
Senior Member
Senior Member
Posts: 208
Joined: 2003-05-13, 13:18 UTC
Location: The Netherlands

Post by *silencer »

Confirmed also in TC 7.04a.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48088
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

c:\dir1\\dir2 is valid path for FindFirstFile, so TC doesn't modify it.
Author of Total Commander
https://www.ghisler.com
serg_joker
Junior Member
Junior Member
Posts: 18
Joined: 2009-08-27, 14:51 UTC

Post by *serg_joker »

Sure it is valid. The path "c:\dir1\..\dir1\dir2" is valid also, and is modified when we try to cd there to "c:\dir1\dir2".

The problem is not that path is modified or not. The problem is that if the path contains double backslashes ("\\") then context menu inside this directory does not contain Explorer items.

Just try it.
serg_joker
Junior Member
Junior Member
Posts: 18
Joined: 2009-08-27, 14:51 UTC

Post by *serg_joker »

I'm sorry, can someone just let me know why this bug is rejected ?
Is it "By design", "Time consuming" (I don't think so), or there is some other reason ?
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

I'm not sure how \\ is valid? The only place I have ever seen it would be on mounted folders:
\\?\Volume{*}
Which is always the first 2 slashes not a \Folder\\Folder2.
Even explorer wont go to a folder like: C:\Program Files\\Accessories
serg_joker
Junior Member
Junior Member
Posts: 18
Joined: 2009-08-27, 14:51 UTC

Post by *serg_joker »

Explorer is not the etalon. Try use cmd.exe and use "cd c:\Program Files\\Internet Explorer" it should work.

Again, there is no problem if total gets \\ in the path. There is problem that when the path contains \\, we get wrong contents of context menu.

BTW, in total we get 2 different behaviors:
1. try edit path in corresponding edit box directly and put doubleslashes there - total will replace it with single slashes.
2 - try use cd from command line - doubleslashes are not replaced.

Regards,
Sergey.
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

I believe there is a difference between double slashes being ignored by cmd.exe, choked on by explorer and the fact that totalcmd handles them differently depending on entirely on context... than they saying they are "valid".
H:\_H_\_APPS_\_FileManager\TC+sac>cd \\XP
'\\XP'
CMD does not support UNC paths as current directories.
H:\_H_\_APPS_\_FileManager\TC+sac>
H:\_H_\_APPS_\_FileManager>cd TC+sac\\XP
H:\_H_\_APPS_\_FileManager\TC+sac\XP>
Yet, according to MSDN 2.2.1.4 UNC Path,
A UNC path can be used to access network resources, and MUST be a null-terminated Unicode character string whose format MUST be \\<hostname>\<sharename>[\<objectname>]*
Which again, the \\ is leading.
Post Reply