Announcement

Collapse
No announcement yet.

windows comparison of shortcut (.lnk) files

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • windows comparison of shortcut (.lnk) files

    Hi,
    I can't find any references to this even though it must have been seen before.
    In folder compare, when .lnk files are shown, their content can be compared as expected, in a new tab.
    However if you save that session and re-open it, the contents are not compared.
    Instead the shortcuts are resolved to the files they point to.
    Is there a way to suppress this?
    Many thanks,
    Ed

    (Using BC4, latest version for Windows)

  • #2
    Hello,

    How are you launching BC4 in a way that follows and shows the .lnk target? The Folder Compare is expected to always show the .lnk as a link and not the target. If you use the Windows Shell Extension to directly select and right-click -> Compare, this would work but the paths would be the Target of the link, and basically never references the link once within BC4. Saving the session, closing, re-comparing, would all use the real path rather than the .lnk file.
    Aaron P Scooter Software

    Comment


    • #3
      Aaron,
      Sorry for delay in replying.
      I think I see what you are saying, but I attach the workspace and session saves that I did at the time.
      I was looking at .LNK files and opened a folder view just to see (via CRC) when they were changing.
      I then Rt-clicked and used Compare to so that a new tab was opened. This did what I wanted and showed me a hex comparison of the .LNK contents. Saving that tab as a Session did not do what I expected, comparing the pointed-to targets instead of the .LNK contents.

      I somewhat question the usefulness of following the link without clear feedback to the user that this has been done.

      Many thanks for your attention, and best regards,
      Ed
      Attached Files

      Comment


      • #4
        Hello,

        I'm attempting these steps but not seeing this behavior in BC 4.1.9. If you update to the latest release, do you see this fixed? All 4.x updates are free for 4.x users, using the website or the Help menu -> Check for Updates.
        Aaron P Scooter Software

        Comment


        • #5
          Hi Aaron,
          Thanks for your reply.
          I have updated to 4.1.9, and the behaviour seems the same.
          I attach three screenshots showing a folder compare, the effect of dbl-clicking A.LNK, and then reopening the saved session of the latter tab in a new one showing the comparison of the target files.
          It might be what you expect, but I was surprised by this.
          The re-opened session does not even let me know the location of the A.LNK files.
          Best regards,
          Ed
          Attached Files

          Comment


          • #6
            Of course, this morning I re-test and both see this behavior *and* the developers tell me it's intentional.

            We're resolving the .lnk targets automatically whenever they are not a child session (their own session, drag and drop, etc). We only compare the .lnk directly when launched as a child session from a Folder Compare.

            If you need to compare these files specifically, you could save a Folder Compare with File Name Filters to show only the needed .lnk files and auto-run a Rules-based scan. Or you can create a Symbolic Link to the .lnk, and give the symlink a name that does not end with the .lnk extension. This will resolve one level automatically and compare the .lnk binary content.
            Aaron P Scooter Software

            Comment


            • #7
              Hi Aaron,
              Thanks for your reply.

              I've been playing with this and what happens is even more confusing.
              Firstly, clicking on one of the address bars in the reopened session
              causes the bar to change to the address of the .LNK file.
              Clicking on the other address bar toggles the first back to
              the target file's path and the second to the the .LNK file!

              Furthermore, if a .LNK file is invalid, the error message implies that
              it is the .LNK file that cannot be found. This is misleading because
              it is the target that cannot be found.

              In view of the above, don't you think this should be treated as
              bug?

              Best regards,
              Ed

              Comment


              • #8
                Hello,

                The path switching is intentional. The given path is what is shown during an attempted edit, but the target path is displayed if we are auto-following to the target.

                For the File Not Found error displaying the wrong text, I'll open a tracker to investigate this.
                Aaron P Scooter Software

                Comment

                Working...
                X