The page has unconfirmed changes. Use the buttons below to see older versions.
Buvt Discussion etc
Two tools in one
File verification
Hashcodes (checksums) are calculated and stored in a db-file (by default called buvtDb.txt (and stored in the root level of the source-tree / target-db-tree))
Under the "Check"-tab one can check the files. That is, for each file-entry in the db the hashcode is recalculated and compared to the stored value. If errors are found they are displayed.
Backing up
Similar to rsync for example.
Why differential copying (only copying the files that have changed)
Avoiding unnecessary writes is important for several reasons, It...
- ...takes unnecessary time.
- ...propagates soft errors.
- ...wears out the storage media. (Given that they have limited number of writes).
Similarly for the recalculation of hashcodes. If there in fact is a soft error, then you
do not want to recalculate (and overwrite the hashcode) (Instead you want to keep the old hashcode so the corrupt file is detected when you click "check" next time.)
Comparison with rsync
Buvt deals with renamed files
You may think "I don't rename files that often" but consider that you rename or move a folder, especially a top-level one, then all the containing stuff will be rewritten (using rsync).
Personally I think filesystems should/could have a separate hashcode field.
Rather than having a separate database to store hashcodes, one should be able to store them in a field in the filesystem.
When the file is copied, the hashcode could be copied along (sort of like how the mod-times etc) can be copied along.
Actually many filesystems already have support for Extended file attributes.
