Frankly, I have never, ever, heard of anything like that in N900 - especially that, as you claim, full reflash of vanilla+combined doesn't fix it.

I would suggest to check for bad blocks via fsck, but, considering that eMMC have transparent hardware wear leveling, no bad block should manifest itself on the same file twice, after reflash.

But, isn't /var/lib/dpkg/info/mafw-tracker-source.postinst on rootfs? It would explain why fsck turns out clean, as it's fsck'ing only /dev/mmcblk0p2. Also, storage used for rootfs *doesn't* have hardware leveling (thankfully), wear control is implemented via ubifs on filesystem level.

Thus, it is possible that during every reflash, the same bit of information (file in question) land on exactly same block. It the block is damaged, file ends corrupted. I'm not aware of any fsck-like tools for ubifs (fixme?), as it's completely resistant to logical filesystem corruption. Probably, it have some tools to handle physically damaged blocks, but it would require digging into ubifs documents.

No matter what, take all of the above with a grain of salt - it's just theory that popped up in my head, while writing this very post. I may be wrong totally (as I don't have possibility to check this file physical location right now), or in any of mentioned things.

Nevertheless, you may workaround your problem by editing backupmenu code (the line where it tar's your files into backup), using tar option to exclude given path from backup (see tar --help). This will produce valid backup lacking this one problematic file - for .postinst in question, it shouldn't be problem. at all. Unless my theory about bad rootfs block is valid, and, after recovering backup, you will end with another file (from backup) jumping into corrupted position of mafw-tracker-source.posints... But, there is a good chance, that as bad block it wouldn't be removable too, during rootfs nuking phase of recovering backup.

/Estel