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.

Version 3.78. Tagged as 'FileCore-3_78'