(Specifically, if the goal is to monitor changes as they happen and the service can be assumed to be continually running.)
[0] http://linux.die.net/man/8/incrond
EDIT: As a use case example I use this to detect when a new cert request is made to my Puppet master server. Once a CSR file is created, I check if the host is created by our provisioning system, and if so, then sign it.
EDIT2: This will eventually go into 3.4.0 - https://projects.puppetlabs.com/issues/7244
Windows seems to have a low-level api for querying the filesystem/vfs for changes since you last looked: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
And BTRFS has some ability to do this with find-new: http://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-fi...
It's nice that btrfs has these new interesting features, also see send/receive, but it's not available in the vfs, and I suppose never will be.
Using sha256 just to compute changes is probably overkill. Using md5 instead is almost certainly adequate and will be a good deal faster.
You could always try it and see :)
Example test: openssl speed md5 sha256
As for why it was chosen, I think it's because there are known examples of MD5 hash collisions (though the likelihood of it on a filesystem is remote) and likely SHA-1 was skipped because it's considered 'likely' a collision could be created (though so far only with weakened versions of SHA-1).
But - all this to say: The chances of having two files with the same MD5 hash that are identical in size is vanishingly small. As such, for the known MD5 collision mechanisms, the different file size would be enough evidence something has changed.
... Why he didn't include file size in the metadata check, I can't tell you. Timestamps can be faked - but generating a hash collision with a file of equal size is a Hard problem.
>> You could always try it and see :)
>> Example test: openssl speed md5 sha256
When I was looking for a fast hash easily called from Python, I settled on adler32 (as the fastest) after some trial-and-error on my files. I don't now recall all the utilities/functions that I tried, but they certainly included md5, sha1, and crc32. I only needed to test for accidental corruption, and only computed the hashes if meta data matched.
I haven't thought about the filesize/hash to reduce collision, but I chose to stick with the last-modified time in the article, because it can takes hours computing hashes for a big directory tree.
Tools like rsync relies on last-modified time by default, and since I want to use this to track my own files, I won't fake it, so I think it's not a big deal?
Compatibility:
Linux 2.6 (inotify)
Mac OS X (FSEvents, kqueue)
FreeBSD/BSD (kqueue)
Windows (ReadDirectoryChangesW with I/O completion ports; ReadDirectoryChangesW worker threads)
OS-independent (polling the disk for directory snapshots and comparing them periodically; slow and not recommended)