No announcement yet.

Synchronize after changed name in source folder

  • Filter
  • Time
  • Show
Clear All
new posts

  • Synchronize after changed name in source folder

    Maybe this has been asked earlier, cannot trace anything right now.

    Starting point is files in different folders are identical.
    I rename the files in the sourcefolder.
    (size, source and dest.folder obviously remains the same)

    WHen synchronizing, the files in the destination folder will remain
    untouched, the 'new' files, same as the old ones, but with a different name, will be added.

    Is there a way to avoid this?


  • #2

    You can use the BC3 Pro feature Alignment Overrides to align the files based on a rename rule as long as they are still in the same basic folder structure. The Alignment Overrides are in the BC3 Pro Folder Compare's Session menu -> Session Settings, Misc tab.

    This will align the files as a pair and allow you to compare them, even if they have different names. How does that work for you?

    BC3 does not run in the background and does not track 'renames'. We align based on file name, so if at the time of the comparison the file names do not match then we currently treat them as different files (new orphan on the Source side, and orphan on the Destination side.)
    Aaron P Scooter Software


    • #3
      Thanks for the feedback. I did have a look at the Help file on this, as I am unfamiliar with this.

      Frankly, I am not sure I fully understand the examples given, no doubt my lack of knowlegde, thát's what I am sure about ..

      Anyway, this is the scenario:


      sofar so good.
      now, I rename the files123.doc in the source-folder to 'my-vacation.doc'.
      date/time/size: no change of course.

      In this situation I would like to have files1234.doc in destfolder deleted and replaced by my-vacation.doc

      Most likely this is (close to??) impossible for Beyond Compare: how shd it know what I have been messed up..., i.e. how should BC3 know what file is originally linked to what other file.

      I was hoping there would be a way to solve this, comparing the original with the renamed file, based on a unique crc/sha-1, md5 or so.

      But I just did a check: original and renamed files have different hash results,
      (crc, sha-1, md5 are different).

      Bad luck... :-(

      So I guess there is no way for BC3 to link the files.

      Bad luck.
      Last edited by bcdewul; 11-Jan-2011, 03:59 PM.


      • #4
        Originally posted by bcdewul View Post
        But I just did a check: original and renamed files have different crc, sha-1, md5 . . . :-(
        Unfortunately that's not surprising. Office modifies files every time you open them, even if you don't make any changes. I think it has an internal "Last Accessed" timestamp and maybe username, but I've never looked into it in depth.
        Zoë P Scooter Software


        • #5
          Renaming Office files using WE or BC should not change CRC, because the file doesn't change but only the directory entry.

          Opening/closing files without changes should be reverted to their original state with the same CRC (tested with Office 2007).
          Opening/closing files discarding changes aren't reverted to their original state (the directory entry seems to be the same, but internal changes occur, maybe timestamp/user as Chris mentioned), so CRC and/or binary compare show a difference.

          Greetings Lutz


          • #6
            Just for info, I used IgorWare Hasher
            which is, a) free b) portable...

            2 files different folders, identical (copies)
            file-xyz17nov.pdf in sourcefolder
            renamed-file-xyz17nov.pdf in dest. folder.

            Name: file-xyz17nov.pdf
            SHA-1: edb0cd45d5c65613d9d9b6234f018166ca1d9090
            MD5: ab058386a92758573fc32634bdc83d44
            CRC32: 77726023

            Name: renamed-file-xyz17nov.pdf
            SHA-1: 97b0ead094e1b2d6e9e61e5693ebb840894f202e
            MD5: 01123321c2769f9c51d3b97dabfdf120
            CRC32: 5e5f9dbb

            i did not open the file, just gave it another name.

            this just for yr info.