Bug: Impossible to compare root dir without trailing backslash

[Scoox]

I think this is a bug. I am trying to run a folder comparison from a script. For argument's sake I'll use an Explorer shortcut to replicate the problem.

Create a shortcut to bcompare.exe and put it somewhere on the C: partition.
Copy the same shortcut to a folder on another partition, e.g. D:.

Shortcut 1: C:\DIR\bcompare.lnk
Shortcut 2: D:\DIR\bcompare.lnk

Shortcut points to: c:\portable\bcompare.exe c: d:
(surround with quotes if required)

NOTE: This only happens if the trailing backslash '/' is omitted, i.e. you need to type c: not c:\, and so on.

Expected result: When either shortcut is double-clicked, BeyondCompare should compare the C: and D: partitions.

BUG: What actually happens is that when Shortcut 1 (from C: partition) is run, BC compares C:\DIR <-> D: instead of C: <-> D: . Likewise, when Shortcut 2 (D: partition) is run, BC compares D: <-> D:\DIR instead of C: <-> D:. When the path input box is clicked it changes back to c: or d:, but when it loses focus BC restores the incorrect path.



This only happens when the comparison involves a root dir without a trailing backslash AND BC is started from a path whose root is the same as the root being compared.

The workaround is to include a trailing backslash after the drive root.

[Aaron]

Hello,

This is actually how Windows Vista and newer handle the folder path "c:". If you want to reference the base of the C:\, it has to be fully passed in with "C:\".

The Folder Compare's base folder path will display the current path, and if clicked on will displayed the path typed in (or passed from the command line). You can type "%AppData%", "%TMP%", or "%WinDir%" as other examples.

[Scoox]

Hello,

This is actually how Windows Vista and newer handle the folder path "c:". If you want to reference the base of the C:\, it has to be fully passed in with "C:\".

The Folder Compare's base folder path will display the current path, and if clicked on will displayed the path typed in (or passed from the command line). You can type "%AppData%", "%TMP%", or "%WinDir%" as other examples.

Hi Aaron, thanks for the prompt reply!

This doesn't only happen with C:, it also happens with D: and in fact any drive letter. I don't understand why there have to be two paths (typed and current/working). If I type c: I expect to get "c:" or "c:\" not "c:\program files\Beyond Compare 3" or whatever.

Furthermore, as shown in my example above, there is one case in which passing c: results in "c:\" and the other case in which passing d: results in "d:\", which means it's not impossible. It all depends on which drive I put the shortcut.

Even if it's not a bug, I just can't think of a situation where this implementation would be beneficial, practical or useful.

The reason why I am being so pedantic about this is because I am trying to do something pro grammatically using AutoHotkey, and my script would be simpler if c: always meant c: and x: always meant x:.

[Zoë]

Hi Scoox,

Sorry, Beyond Compare is working as designed, and this probably won't change. Even if we decided to, it would have to wait until a major version upgrade since it could break other people's scripts.

The command prompt (cmd.exe) keeps track of the working directory on each drive separately, which is why you can change into a directory, change drives, then change back and be back where you started. Using a path like "C:" without the "\" means that we should use the working directory for that drive. For example:

C:\> cd Dir1
C:\Dir1> D:
D:\> cd Dir2\Dir3
D:\Dir2\Dir3> C:
C:\Dir1>

Other command line utilities can support that too. After the steps above, if you then do this:

C:\Dir1> E:
E:\> copy C:* D:

It will copy everything in C:\Dir1 to D:\Dir2\Dir3. You can put anything you want after the colon and it will be treated relative to that working directory, so things like "C:MyFile.txt" or "C:..\Dir4" work. Explorer unfortunately doesn't support any of this, which is probably why you aren't familiar with it.

The reason you're seeing the behavior you are is because unlike cmd.exe, the shortcut only has a single working directory. The working directory for any drives besides the one given in the "Start in" edit are assumed to be that drive's root.

[Scoox]

Thanks Aaron, I didn't know cmd.exe keeps track of each drive's working directory, so I guess what you are saying is that BC conforms to the same standards as cmd.exe, in which case that's fair enough