I agree with you, trevyn. But disks shouldn't fail either, and they do. When a system isn't performing properly - whether due to memory issues, disk failure, controller failures, etc - we can only work with what we have... and if an error isn't flagged, or is ignored, it's difficult to know what to do.
I've never seen anything similar to what you've experienced here, and as I've said I do thousands of tests. But if your system is corrupting data -- for whatever reason -- we'll be a victim of that corruption just like any other application might be.
Memory on a non-MacPro isn't ECC and doesn't have parity, so memory errors will not be caught by the system. And, if a drive fails to write but does not flag an error to us, there's no way for us to know, unless we were to checksum every source and destination file during every copy: something that would be prohibitively slow, expensive, would cause additional wear-and-tear, etc. And even
that can't guarantee everything'll always work right (plus, an active system is always changing, so you'll have errors each and every time you ran).
We've worked very hard at this end to only use well-tested functions that leverage as much of Apple's work (and OSX) as possible. And, in our testing, these functions have been reliable. Where we've caught errors (such as missing metadata) we've made extensive efforts to supplement those calls (and this has been
verified by third parties who have found us to be the most accurate copying engine). But we've never seen them mis-copy existing data, even once, in all our testing.
I'll do my best to try to reproduce the problem... but as I've said I've never seen anything like it before, so I'm not hopeful.