trapexit

> Maybe store mtime along with the hash, and have an option to ignore changes if the mtime on the file is newer than in the db? mtime, inode, size,...

That said... if you don't care about NFO files then just add -F -f ".*\.nfo" and it'll only process files that don't match ending in ".nfo".

You can use `--maxdata` and/or `--maxactions` to do more regularly checks (with `--sort=random`). You'd catch things more quickly. I prefer to talk in terms of general features rather than implementations....

re regex: `^.*\.(ext1|ext2|ext3)$` That will match those extensions. If you want to easily negate the regex just use `-F`.

re changes: if you want to index the files but don't care about changes (or want them emailed at a different time) you could use different databases for them and/or...

What I'm getting at with these suggestions is that I'm not sure it's a good idea to ignore changes wholesale. It is better to have different checks for different usecases...

I'm not sure I understand. If the file is modified regularly then the whole "silent" part of "silent corruption detection" is no longer a thing because it will be found...

> When I found your project I was given the impression that the scorch is generic tool to detect file corruption on best effort basis and README.md was written in...

I'll change the verbosity settings. update should have been silent by default anyway. But what I'm really trying to understand is why you index files in which indexing isn't useful....

regarding hashdeep The problem with those tools is they don't fit the problem space of the typical data hoarder. There needs to be a way to indicate a file has...