GitLab

When handling fsfile_ReadInfo, PipeFS wants to wait for any writer to
close the file before returning the file information. To do this it
repeatedly calls FindFileOrDirectory & blockifwriting in a loop until
that condition is reached (or the file ceases to exist). However the
call to FindFileOrDirectory was replacing the filename in R1 with a the
internal file handle (i.e. a pointer to a struct), so on the second loop
round it would always exit out with a "file not found" response.

This bug had the effect that attempting to read the size of a file (e.g.
using OS_File 5 or *FileInfo) which is open for write would always
report that the file doesn't exist, even if the blockifwriting call
successfully blocks until the writer closes the file.

Restoring R1 before looping back round will give the behaviour the
programmer originally intended, for better or worse (e.g. current
versions of FileSwitch use fsfile_ReadInfo to check the file before
trying to open it, so trying to use OPENIN on a file which is open for
write will unintentionally block - a bug that was hidden on earlier
versions of RISC OS because prior to TaskWindow 0.65, TaskWindow didn't
make any attempt to wait until the pollword was non-zero before
returning, so PipeFS would pretty quickly exit out with a harmless "file
not found" response due to the register corruption bug)