[lmilcin]

In vast majority of cases corruption (that doesn't involve drive failure) happens due to bad or naive implementation of software that handles files.

While memory does fail sometimes, if it was failing at the rate you describe PCs would not be suitable to any work at all.

I have worked in ops for many years. A lot of software that copies files is perfectly happy to leave you with copy of different length than original.

[abcd_f]

Software bugs is an altogether different issue. As it is a far more exotic one.

The context of the OPs post and my reply is the case when copying in bulk with a mature tool yields corruption in a small fraction of the data. In this case the cause is the in-transit corruption (rather than at-rest, which is a fairly common belief dubbed as a “bitrot” phenomenon).

[lmilcin]

Software bugs exotic. That is funny.

File IO is one of more error prone activities with low understanding by general software dev community.

It is actually rare to see a piece of code that is NOT broken.

I had once observed a piece of software write a million files, all empty, because it could not handle situation where it could create file but not write it.

It is quite normal for files to be truncated because written directly to destination file rather than through temp. Then script gets killed and next instance assumes file exists so it resumes from next.

Most software can do the job if everything works, but almost none can correctly handle every error condition.