An oddity

I have an ARMX6 running RO5.29 21-Dec-2022, standard TCPIP, and a rPi running 5.29 22-Dec-2022, ROD TCPIP 7.03

The ARMX6 is acting as a server for a directory of BASIC programs.

I can run any of those programs on the rPi from the shared disc. However if I edit one of those programs using the ARMX6, then try to run it again on the rPi, I get “Bad Program”. It continues to do this until I reboot the rPi. If I undo the edit, the program will run without requiring a reboot.

I don’t recall seeing this until very recently – about the time I changed the ARMX6 RO version from the Dec 2020 version to the DEC 2022 version, and changed the TCPIP on the rPi to the ROD version.

I have just tried it with the rPi reverted to the original TCPIP. It still does the same thing.

This might be a coincidence. Or not. Does anyone know any more about this?

I can hazard a guess as to what might be going on.

• When the client displays shared directory, it will show the contents pre-edit. Let’s suppose that the program to be run is 2000 bytes long.
• The program is now edited to be 2005 bytes long. The client machine is not informed of this change.
• The client tries to run the program, so transfers only 2000 bytes of the file. As this is missing an end-of-program marker, it will generate the “Bad Program” error.
• Rebooting the client will retrieve the post-edit contents of the directory. This correctly gives the program size as 2005 bytes.

This can be checked by displaying the file size on the remote machine (“File > Info”) before and after the edit. Also try using the “Refresh” menu option to see if that improves matters.

Yup, sounds like it might be related to this.

If ShareFS isn’t correctly sending out change notifications (as it wasn’t), then clients may have stale information on the sizes of files.

You’ll need a ROM version on or after March 19th (when the fix was applied). It looks like the brokenness was introduced a year ago in March 2022, so builds after that won’t work correctly.

If ShareFS isn’t correctly sending out change notifications (as it wasn’t),

I can now confirm this suggestion.

( Following edited )

Test1. Launch the program then quit. (Note, it’s launched using a share path without mounting the share first.)
Edit the program, overtyping, so the size remains the same. Launch succeeds. Quit

Test2. Edit the text, making the file smaller. Launch the program again, which worked. Quit program.

Test3. Edit the text, replacing characters but keeping size.
Launch program successfully, quit.

Test4. add a few characters. Launch failed.

Test5. Mount share. Launch from mounted share, fails

Test6. Dismount it. Launch now succeeds.

So it seems that it is possible to clear the cached size by dismounting the share.

Thanks for the explanation, I now have a better workaround than rebooting.

One more thing – is the problem in the serving component, or the client? I can upgrade the ROM image on the pi – the client, but not on the ARMX6, the server.