Feature req: skip already hashed files

  • Andy_Scull

    Andy_Scull - 2008-12-31

    When adding files/dirs, there should be an option to 'skip already hashed files' that you have in database.
    It's for a situation when you add some files to a directory and do not want to add them manually or do not ever know their filenames.

    • Tom Bramer

      Tom Bramer - 2009-01-05

      I'm adding an option that if set, each file will be checked against the filesystem metadata (size and modification date), and if the file matches an entry of the same path, it will be skipped.  I think this would be the safest way of doing it.

    • jacktrip

      jacktrip - 2009-06-13

      Please consider adding an option to skip already hashed files when adding files, regardless of whether a given file's filesystem size and/or modification date differ from that of the result set. Here is a scenario showing what I currently do, to show why such an option would be useful:

      a) Open a result set containing all executable files on my system (.exe, .dll, .ocx, etc).
      b) Do 'Verify All'. Any files with state of 'Invalid' or 'Error' are given attention. A new hash is calculated for 'Invalid' state files for which a change is considered acceptable. 'Error' state files which have been deleted from the filesystem, and for which deletion is considered acceptable, are deleted from the result set.
      c) Do add of executable files on my system, with option 'Don't recalculate known good items' (the option that was added to FileVerifier++ that addresses the first feature request in this thread) turned on. Files with state 'Not Checked' are given attention, to see if unwanted executable files (possibly malware) have been added to the filesystem.
      d) Save result set, in preparation for the next cycle.

      The problem is that this is not quite airtight. If, in between steps b and c, a file in the result set as of step b has since changed in the filesystem, and the change causes the file's filesystem size and/or modification date to change, then FileVerifier++ in step c will calculate a new hash for the modified file. In this case, after step c, I would probably not notice that a file already in the result set has been modified, because there is no way to distinguish between those files that are new to the result set from those that already existed in the result set but had a new hash calculated in step c.

      I humbly request the following feature to address this scenario: there should be an option for what FileVerifier++ does when adding files that already have existing entries, including hash, in the result set, with these 3 choices:
      1. Always calculate new hash. This can be accomplished currently by turning off option 'Don't recalculate known good items.'
      2. Calculate new hash only if file size and/or modification date differs between the result set and filesystem. This can be accomplished currently by turning on option 'Don't recalculate known good items'.
      3. Never calculate new hash. This cannot be done currently. If there were such an option, then the aforementioned scenario could be accomplished without the aforementioned problem.

      P.S. As this is my first post, I would like to thank you for the program!

      • Tom Bramer

        Tom Bramer - 2009-06-22

        It seems like this would be a good feature to have.  This might involve some rework as to how such is specified though (this should be selectable when performing the operation, as opposed to as an option outside of these operations). 


Log in to post a comment.