GitLab

Here's a bug that's probably been around forever, but was recently observed when running FSBash on Raspberry Pi.

When a file is extended by OS_Args, either by setting the extent directly or by setting the file pointer beyond the current end of the file, FileCore is the entity that is responsible for filling the intervening space with zeros. This it does by constructing a scatter list in the scratch space. However, there's a problem with that, because if it has to mount the discs in one or more drives in order to establish which drive contains the disc which holds the file being extended, then that mount operation also needs to use the scratch space. This happens particularly frequently on platforms like Raspberry Pi where there is no hardware media insertion detection, which means that we have to assume the media might have changed after a timeout since the last sucecssful data operation. However, it would also affect any other removable drive if the media was removed and reinserted since the last DiscOp.

What appears to have ended up happening is that the boot block of the mounted disc was loaded to the scratch space, then interpreted as a scatter list. The defect list terminator, &20000000, happens to point at the base of the RMA, so rather than extending the file with zero bytes, the start of the RMA got copied there instead.

Fixed by explicitly calling FindDisc just before we start to construct the scatter list in scratch space.

Successfully soak tested with FSBash for 6 hours.