GitLab

One of the fixes in PipeFS 0.25 was to fix the fsfile_ReadInfo operation
to block until the pipe is no longer open for write (instead of failing
with a "file not found" error, as it had done previously). This fix had
some knock-ons for FileSwitch, since the contemporary version (2.89)
only made use of fsfile_ReadInfo. E.g. trying to open a pipe for read
while it's open for write would block due to TopPath_DoBusinessToPath
using fsfile_ReadInfo when FileSwitch is checking whether the file
exists. This specific issue was fixed in FileSwitch 2.90 by changing
some areas of FileSwitch to use fsfile_ReadInfoNoLen instead.

Further testing has revealed a few more areas which are making
unnecessary use of fsfile_ReadInfo and have the potential to break
programs. Specifically, with FileSwitch 2.90 & PipeFS 0.25, programs
which use GCC's UnixLib will get stuck if they try to open a PipeFS file
for write while running in a taskwindow. E.g. the call to GNU.gawk in
Env.!Common. This happens because after opening the file, UnixLib
attempts to set its attributes using OS_File 4, which in turn causes
FileSwitch to attempt to examine the file using fsfile_ReadInfo.

Fix this issue by changing OS_File 4 to use fsfile_ReadInfoNoLen, along
with all the other applicable OS_Files: 0-3, 7-11, 18, and 24. For
OS_File, this leaves just OS_File 5, 6, 12-17, 20-23 and 255 using
fsfile_ReadInfo, since they all need to return the length to the caller,
and OS_File 19, which doesn't use fsfile_ReadInfo at all.