Writing to a REL file does not work when simultaneously reading from an open SEQ file

[tonedef71]

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: (MEGA65, xemu)
• ROM Release: (i.e. 920409)

Describe the bug
Writing to a random-access RELative file does not work when there is also a file descriptor open to read from another file.

To Reproduce
Steps to reproduce the behavior:

1. MOUNT the attached .D81 disk image.
2. LOAD and RUN program "TEST".
3. Examine the contents of the REL file "RELDATA" on the disk and notice that it only contains one sector of empty records instead of multiple sectors of five-character records with actual values.
4. Notice also that the reported block size of the "RELDATA" file on the disk is zero.
5. LOAD and RUN program "TEST-ALT".
6. Examine the contents of the REL file "RELDATA2" on the disk and notice that all one thousand of the five-character records in the file have the same exact five-character value.
7. Notice also that the reported block size of the "RELDATA2" file on the disk is twenty-two.

Expected behavior
I expect that when a file descriptor is open for a RELative file at the same time as another file descriptor is open for reading a different file, it should still be possible to properly add and update record entries within a RELative file with the data that is read from the file that is open for reading.

Screenshots
N/A

Additional context
In the "TEST" program, the RELative file is opened before the SEQuential file is opened. The reads from the SEQuential file are successful, but the writes to the RELative file are flawed. In the "TEST-ALT" program, the SEQuential file is opened first and then the RELative file is re-opened and re-closed for each iteration of the DO loop. The reads from the SEQuential file are flawed, but the writes to the RELative file are successful. It is as if one cannot "have their cake and eat it, too."

Relative_Files_Test_Disk.zip

[snoopy-f64]

If you first open the sequential file (#1) for reading and then the relative file (#2), then your example “TEST” will work:

Oh, I see, it creates a file with the correct size (22 blocks), but with the wrong content:

[tonedef71]

Thank you for sharing those screenshots @snoopy-f64!