#395 Comparison by content: Option: depending on the size.

closed
nobody
2013-06-20
2013-04-24
FireLink
No

It would be interesting (to me useful) to set this method to analyze the files are identical but with different name and decide on necessary actions like: rename the file, the date of creation and modification, (and at the same time) identify the different files and missing.
Thank you.

Discussion

  • Zenju
    Zenju
    2013-04-28

    I don't understand this request. Can you elaborate which option exactly you are asking for?

     
  • FireLink
    FireLink
    2013-05-04

    A different approach to search: file size instead of name: It can be useful to quickly locate files renamed but identical (possibly unintentionally copied or moved to different folders) and at a later time may be possible to launch a session of comparable bit-bit or md5 (to eliminate any doubt).

    P.S. Perhaps an analysis of quersto guy could make obsolete and useless the .db archive.

     
    Last edit: FireLink 2013-05-04
  • Claude V
    Claude V
    2013-05-08

    I would love this feature too. I was thinking at creating such a feature request too when I discovered this one. Identifying renamed and/or moved files was on the top of my wish list, considering that FreeFileSync already answers most of my wishes.
    For such files, it would be great to avoid transferring them as part of a backup job (i.e. no change to the source set). In case of a renamed (or moved) file, instead of displaying in the comparison window the renamed file as new (+) on the source side and the old file as not found (-) on the target side, it would be good to have something else (this isn't an "=" either) showing that the file was renamed/moved (if its content is indeed the same).

    A hint for finding these renamed/moved files could indeed be to check for files not found on the target side if there is a matching "old" file. The match could be based on the size, and maybe the creation date, if this is kept. Comparing content for accurate matching could be the second comparison step to ensure that his is indeed the same file.

     
  • FireLink
    FireLink
    2013-05-08

    The creation date should not be taken into account, (personally I can not help it to remind me when I did things) because they are rare programs that keep original.

     
  • Zenju
    Zenju
    2013-05-25

    Detection of moved or renamed files is already implemented for the "two-way" sync variant, but it may be added for the other variants, too, then requiring a database file:
    https://sourceforge.net/p/freefilesync/feature-requests/299/

    it would be good to have something else (this isn't an "=" either) showing that the file was renamed/moved

    Conceptually "renaming/moving" in FFS is just an optimization of copy/delete and not a fixed category like "existing on left only/left side newer/ect.". For example if a file is renamed on one side, the move will only be applied if the sync directions of the two resulting row items are the same. If the user changes the directions to copy each file to the other side, it's naturally not a rename/move operation anymore, but two creates.
    Also it's not always possible to detect renamed files if the underlying volume does not support file ids, so it's probably better to really think of this as a performance optimization rather than a categorization.

     
  • Zenju
    Zenju
    2013-05-25

    • status: open --> closed