I am (at a superficial level) aware of the issues you pose. I understand that the underlaying physical medium could be OK, yet the actual data (the 0s and 1s forming the file) could be corrupted. For example, a 0 could be written instead of a 1 somewhere. In this case, any tool like fsck would say the card is OK (and it is), but the file in the card would not match the original file (that I could check with a checksum, or even diff). I was just assuming that the only reason for a file being corrupted was a failure of the underlaying medium, which of course is not true.

However, to do such exhaustive read-writes of an SD card would probably reduce its’ service life significantly, especially if left on overnight or for a week! SD cards (and flash devices in general) are so cheap these days, why would you bother? Even a 16Gb microSD is “only” US$50.

Sandisk announced several years ago that their company vision was to make SD so ubiquitous it would be like film, something so cheap and available that you write a card once then keep it forever.

See, fsck only checks the filesystem itself – in other words, the structures that let you store files on there and then find/recognize them afterwards – not the actual data in the files. There’s a crucial difference there, though I suppose it might not be obvious to a layman.

What it means is that, most likely, the data sectors that make up the filesystem structures are OK, but there’s one(or more) sector(s) that contains file data that isn’t – in other words, the filesystem (which is what fsck checks) is OK, but some of the data that the installer requires to function, is not.

While I can only guess, I figure that the write probably didn’t return an error, but that the data didn’t actually get written properly – either that, or the read fails.

The only real way to check for the former kind of error, that I know about, is to write the data you need, and then read it back to compare with the original (probably via a checksum like e.g. MD5).
This takes time though, so most copy operations don’t do it, you usually have to ask for it explicitly or do it manually afterwards. Also, to be really sure, you’ll have to flush any caches first (at minimum unmount then mount, in this case it’s probably a good idea to eject the card and then reinsert it).

A further issue, which compounds the problem, is that such write errors can be data dependent. In other words, the sector might work perfectly for one set of bytes, but not for a different set.
This makes testing difficult, as it’s practically impossible to test all sets of bytes (block sizes being generally 512 bytes minimum, often more) in any kind of reasonable time. Because of this, even comprehensive tests only tests certain patterns.
Note that this is something I know from RAM tests – while I believe it to be true for flash as well, I technically don’t really know that.

OK, OK, I know I’m being naive. Any test of a given system is a multi-variable problem, with many different things to check, values to measure and inferences to make from the collected data. I just wanted to protest a bit.

This stems from the fact that software is an inferior way to test hardware. What you really need is something that can test the SD card at a low-level electrical level. However such a device would probably cost more than we’ll both earn together this year, so we make do with what we have.

I agree that fsck-on-battery shouldn’t be automatically skipped, however I think an interactive option (perhaps with a short timer to skip by default) would be ideal.