DiffMerge behaves strangely with links to folders (Windows)

[hustbaer]

I have noticed that, when doing a folder-diff, DiffMerge does some strange things when you have links to folders in one or both of the compared folders.

By links I mean the normal .lnk Windows Explorer link-files.

What I observed:

1) If the drive where the link-target is located exists, DiffMerge seems to treat the .lnk file as an empty folder with the path of the link-target.
When displayed in the folder diff window, the path shown is something like "..\..\target-folder", or even "Z:\target-folder" if the link and the target are on different drives.
It doesn't seem to matter if the actual folder exists, just as long as the drive is there.

2) If the drive of the target does not exists, DiffMerge will display an entry with a "red circle with X in it" icon. Double-clicking that entry yields an error message "Cannot compare items. Both objects must be regular files".

I have encountered this while comparing two versions of a directory-tree, which - by accident - both had a link to some directory V:\... in it. Since my computer doesn't have a V drive, I got the circle-with-X-in-it icon, which was quite irritating, since I had no clue what was going on. Took me some time to figure out what was causing it.

Workaround: enter "lnk" in the file suffix filter list.

I don't know if you have any maintenance releases planned for the near future, but if so, I think that's something you should fix.

EDIT:
At least DiffMerge 3.2.0 and 3.3.0 are affected
Platform is Windows XP (32 Bit) SP3

[jeffhostetler]

That's weird. But I've had another report of .lnk oddities, so
I'm not completely surprised.

I've logged this bug. For now, you should probably keep
using the the the suffix filter.

Sorry I don't have an immediate answer.
jeff

Item:15534

[hustbaer]

Well, it doesn't seem all that weird to me

Since DiffMerge is cross-platform, I guess you're using some kind of portable framework (or just a bunch of portable libraries).
If DiffMerge uses file system functions from such a framework, which follow links for whatever reason, it would explain what's happening.

BTW: do you have any idea when the next version of DiffMerge will be released, and what new features or changes it will contain?

[jeffhostetler]

Yeah, I'm using wxWidgets library/framework for both the
cross-platform OS and GUI stuff. It successfully hid most
of the various OS and GUI differences. It is a really nice
package and I would definitely recommend it if you had a
similar need.

As for the next release, I don't have anything planned at
the moment. I might try to make a November/December
release, but that's very much up in the air.

jeff

[hustbaer]

Had a quick look at wxWidgets.

wxFileName::Normalize follows links on windows if flags contains wxPATH_NORM_SHORTCUT (by calling wxFileName::GetShortcutTarget)

Possible candidates:

• wxPATH_NORM_ALL is the default argument for wxFileName::Normalize, and contains all wxPathNormalize bits but wxPATH_NORM_CASE.
• wxFileName::MakeRelativeTo calls wxFileName::Normalize with wxPATH_NORM_ALL & ~wxPATH_NORM_CASE
• wxFileName::SameAs calls wxFileName::Normalize with wxPATH_NORM_ALL | wxPATH_NORM_CASE
• wxStandardPathsBase::GetExecutablePath calls wxFileName::Normalize with default arguments

Since wxFileName::SameAs doesn't return the normalized paths and wxStandardPathsBase::GetExecutablePath makes no sense at all, I'm guessing you're calling either wxFileName::Normalize with default arguments, or, more likely, wxFileName::MakeRelativeTo, to make the file paths relative to the scanned directories.

After a (direct or indirect) call to wxFileName::Normalize, wxFileName::IsDir will also return true, if the link target is a directory. Which would also explain why the link-to-directory shows up as a directory in the folder-diff-window.

----

Unfortunately wxFileName::MakeRelativeTo has no flags argument, so you can't make it not follow links. But you could always copy it or patch/extend wxWidgets appropriately.