PrestoSoft Community

Conclusion
I then noticed that when ExamDiff compares .lnk files (shortcuts in windows), it is trying to compare the target and start folder of the shortcut rather than the shortcut itself. That alone is a problem as well as the fact that it doesn't bother to expand the environment variable.

Backstory:
A relatively small folder with only 94 files and 11 subfolders with a mix of text and binary (e.g exe, dll, lnk) files takes a full minute. ExamDiff gets stuck at 68% for most of the wait. This happened on version 11 so I upgraded to version 16 and still have the same problem. I've turned off plug-ins, I've tried different view layouts (grouped, not grouped, etc). I've tried various comparison settings as well. I have a high end laptop Win11 Pro, 64GB RAM, and M.2 drive - so its not a lack of horsepower. While it is hung, Task Manager shows ExamDiff using 0% CPU and 0% Disk.

So, finally I used Process Monitor and find that examdiff.exe is stuck trying to open C:\Windows\CSC\v2.0.6\namespace\8022DATABASE (other times it is C:\Windows\CSC\v2.0.6\namespace\6044DATABASE). Both 8022DATABASE and 6044DATABASE are machines that I have accessed in the past but currently don't have access to. I do not have Offline File syncing enabled (which is what I understand the CSC folder to be related to).
I then noticed that when ExamDiff compares .lnk files (shortcuts in windows), it is trying to compare the target and start folder of the shortcut rather than the shortcut itself. That alone is a problem as well as the fact that it doesn't expand the environment variable.

I then noticed that when ExamDiff compares .lnk files (shortcuts in windows), it is trying to compare the target and start folder of the shortcut rather than the shortcut itself. That alone is a problem as well as the fact that it doesn't bother to expand the environment variable.

EDP does not compare link (shortcut) targets, it compares link files themselves. I'm not sure what you meant here: "compare the target and start folder" and here: "it doesn't bother to expand the environment variable". As for the slowdown, it is likely to be caused by resolving each shortcut in order to show the Target column (assuming you have it enabled).

I meant to attach this That's what I mean by Target and the Start in (folder).
Compare those values to the values listed in the Process Monitor - they are the same.

Why would EDP even care or know about those paths if Target column is not enabled?

I was just writing my correction. You are right, EDP also always resolves link targets, whether or not the Target column is visible. We'll have to take another look at this, see if we can delay link resolution.

On further testing, it appears to be related to the fact that the environment variables listed in the shortcut do not exist on my machine (nor will they as my machine is not a production machine, just dev). If the environment variable is set, EDP is fast, even if the environment variable points to an invalid location.

Thanks for letting me know. Bottom line, EDP uses the IShellLink interface for link resolution, and it would use all link properties, including environment variables. The problem in your case that they were pointing to a non-existent directory, hence the delay.

Not exactly, I tested setting the environment variable to a non-existent folder path and EDP was still fast. Its only when the environment variable itself doesn't exist that EDP ends up trying to find a syntactically incorrect path named "C:\Users\uscor4126\Desktop\%LTI_SYSTEMVIEW_PATH%\LtiViewer\LtiViewer.exe", that it is slow.

You are probably right. In any case, that's up to IShellLink, we can't control its behavior.

psguru wrote: Wed Mar 19, 2025 12:47 pm You are probably right. In any case, that's up to IShellLink, we can't control its behavior.

Surely though you could peek at each target string to see if it contains a percent sign, first? And then if it does determine from an option (does it already exist? - I couldn't find anything online for the existence of the "Target" column and how EDP uses the data within) either just to display and compare the literal string (ie usin the environment var names) or the expanded value.

It seems to me that expanded value is somewhat useless as it's often going to depend on the userid & machine name that it's used on, often not the same as the user/machine on which the compare is being run.

In many cases I'd personally be more interested in comparing the non-expanded values.

We will actually have a faster version of link resolution in the next builds of 15 and 16.

The target value is used for display purposes (like the Windows Explorer's Link Target column. Comparison is still performed on the actual links. The target is also used for navigation in case of symbolic links (reparse points).

psguru wrote: Fri Mar 21, 2025 9:05 am The target value is used for display purposes (like the Windows Explorer's Link Target column.

Comparison is still performed on the actual links. The target is also used for navigation in case of symbolic links (reparse points).

But the thing is, the resolved target only shows a resolution by plugging in the current user's values for the symbols, which may be meaningless in the context of how a link would be used by another user, or the intended user(s). The displayed value will be nonsensical in such instances. Clearly it does make sense if it's a system(s)-wide link designed for use by all users...

But even then I'd rather see the unresolved string. It's still useful information. If you offered an option NOT To resolve link targets then (a) all the processing would be faster, and (b) for those of us who only care about the link definitions rather than where they might point to, more useful.

Maybe I'm not explaining my pov clearly enough?

Again, it simply, in case of shortcuts, imitates what the Explorer does. As for the performance, as i said earlier, it will not be an issue.

psguru wrote: Fri Mar 21, 2025 2:48 pm Again, it simply, in case of shortcuts, imitates what the Explorer does. As for the performance, as i said earlier, it will not be an issue.

If I undrstand correctly that gives users a simple choice: don't display the target column (so be none the wiser about what EDP compared), or display it (but possibly be misled).

I'm trying to suggest that it would be better if users who wished to could also choose - to have compared & see the literal value in the shortcut - whether it's a full literal path, or partially/wholely symbolic. Depending on what the comparer is trying to achieve, this third way of influencing what EDP does would be useful to some users some of the time.

Alternatively, how should a user determine the difference between a shortcut whose target is always the same, no matter who uses it, and one which sometimes matches that value and sometimes doesn't? Is there a plugin which will extract the values stored in a shortcut allowing users to compare the literal contents if that's what they want to do?

I'm not sure what problem has to be solved here. LNK files are just binary files, and they are compared as such. The target column is purely information (in case of LNK files), and it is hidden by default.

The original issue, again, will be resolved. We are not likely to have an option specific only to LNK files.

psguru wrote: Fri Mar 21, 2025 3:26 pm I'm not sure what problem has to be solved here. LNK files are just binary files, and they are compared as such. The target column is purely information (in case of LNK files), and it is hidden by default.

The original issue, again, will be resolved. We are not likely to have an option specific only to LNK files.

Saying they are "just binary files" is meaningless, as I should think nearly no ordinary user knows what their contents look like. EVERY file only contains "binary" data (though of course in a plain text file the bytes concerned all have sensible visual representations). It's not possible for any byte in a file not to be binary.

Are you saying that a lnk file which contains (as target) eg "C:\This\That\Other\Somefile.xyz" will ALWAYS be shown as not equal to one that contains (say) "C:\This\That\%blah1%\%blah2%" no matter what the two environment variables' values happen to be for the person who is running the compare? (Or perhaps I mean the implied runner, as EDP might be being run by one user under Admin auth so vars would be resolved from the Admin user's pov.)

So the /compare/ is being strict, but if the comparer has turned on display of the Target column, they won't necessarily see clearly why some shortcuts have been flagged non-equal - the /displayed/ values could be identical but the shortcut contents not...?

If that IS the case ... I re-iterate - how should a user who want to know whether individual shortcuts have entirely literal definitions or partially/wholely symbolic ones use EDP in a way that will be cleary shown?