The bug thread is "Verify errors", here:
http://www.vilett.com/disParity/forum/topic.php?id=46
The bug has only been seen twice so far and in both cases it seemed to involve very large bulk moves of files from one drive to another at some point before an update. I don't know whether the bug occurs on the next update after the large move, or on some further update after that. I added special code to my copy of disParity here that double checks all touched parity blocks after every update, which in theory will catch the bug immediately after it happens. But the bug hasn't happened to me again yet so I haven't learned anything new.
Interesting ideas about the virtual drive project, sounds like something that could be useful to anyone who doesn't want to mess around with WHS.
On-the-fly updates are tricky. There are basically two possible approaches: notice file changes "before" they happen, or "after". Trapping deletes before the file is deleted is nice because it makes the parity update much simpler (no need to read all the other files involved), with the one drawback that it slows down deletes quite a bit. However the only way I know how to do this is at the driver level. I don't believe this is something that a standard Windows application can do. I don't have much experience writing drivers under Windows so there would be a significant learning curve for me to add something like that to disParity.
The other way is to have your app be notified by Windows after changes occur. This is much simpler to do and doesn't require any fancy driver coding. However that raises some issues about the proper timing of processing file change events. You can imagine a naive approach where disParity attempts to immediately update parity in response to any file system change running into problems in a variety of situations, especially cases where large numbers of files are changed at once.
