ShareFS not reflecting changes

I use ShareFS constantly between ARMX6 (5.29 21-Dec-2022) and Pi 400 (5.29 14-Feb-2023) but recently the Filer displays on one end show reluctance to show changes made at the other end. On those occasions when an update fails to register on the ‘other’ machine, Refresh doesn’t help: only copying in or saving to the Filer display forces an update. Is there a known issue in this area?

I was about to post a topic – ShareFS not reflecting changes and had prepared the text when lo! Bernard had already posted it!
It has been happening for at least a month. The only way I have found to force an update is to dismount the shared disc and remount it.
What may be relevant is that I upgraded the OS on two Pis, one to 5.29 (05 feb 23), the other 5.29(26 june 22).

13 Feb 2023 → Freeway → Drop COMPAT_INET4 support
26 Mar 2022 → ShareFS → Drop COMPAT_INET4 support

Has this subtly broken something?

This much is true on ARMX6 5.29(01-Feb-22) with ROD TCPIP 7.

Open a filer window on RAM, then open a shared version of the same.
Changes to the “real” filer window are refelected in the shared window but not vice-versa.

Open a filer window on RAM, then open a shared version of the same.
Changes to the “real” filer window are refelected in the shared window but not vice-versa.

John, that sounds like you’re testing locally, and therefore the issue is all in the ARMX6 and ROD TCPIP build.
Are you suggesting the issue is, possibly, the ROD stack implementation?

Or misunderstanding of your description?

ShareFS occasionally not reflecting changes is something we’ve seen on our network at work for some years, with RISC OS 3.7 & RISC OS 4, so it may be that something is provoking this bug a bit more recently rather than it being a totally new bug.

re accessing shares from the local machine they’re shared from, this can lead to all sorts of problems usually ending in “ShareFS may not be used recursively” errors and needing to switch off and on again.

I wonder whether any of this is common to similar behaviour in LanMan98 – which never shows on RISC OS updates to directories native on Windows. It’s necessary to reopen the window, usually by shift-clicking to open the parent, then clicking to re-open the child.

ShareFS is designed to auto refresh, others such as Lanman98, LanmanFS and Sunfish aren’t.

Problems with auto updating not working in one direction between different machines were commonly due to the network mask not being set identically on both. Check that, and try with the standard RISC OS TCP/IP stack.

ShareFS is designed to auto refresh, others such as Lanman98, LanmanFS and Sunfish aren’t.

If you are running QuickFiler, then F11 will refresh a Filer display. I use it with LanMan98/FS.
A bodge, I know, but useful!

LanMan98 – which never shows on RISC OS updates to directories native on Windows. It’s necessary to reopen the window, usually by shift-clicking to open the parent, then clicking to re-open the child.

Or just click Refresh in the menu.

Problems with auto updating not working in one direction between different machines were commonly due to the network mask not being set identically on both. Check that, and try with the standard RISC OS TCP/IP stack.

I’m curious, would differing netmasks cause auto updating not to work only occasionally, or all the time? When I’ve seen it in the past, it’s worked fine eg. all morning, then suddenly creating a new folder appears not to work, but when you look on the remote machine, it’s there!

[changes] 13 Feb 2023 → Freeway, 26 Mar 2022 → ShareFS
Has this subtly broken something?

I tried all 4 combinations of a version either side of those changes and they all behave the same (not refreshing a remote view onto a drive when a local change is made to that drive) so it looks independent of any recent change.

In case of insanity on my part here are the 4 modules to try. The DebugTools module shows believable looking tickers booked for doing the refresh, but I didn’t go as far as to get the packet sniffer out and look whether one end was sending but the other not hearing.

John, that sounds like you’re testing locally, and therefore the issue is all in the ARMX6 and ROD TCPIP build.
Are you suggesting the issue is, possibly, the ROD stack implementation?

Or misunderstanding of your description?

For the sake of clarity I have ruled out ROD TCP/IP stack as being at fault.
The problem occurs on three machines. One with ROD stack the other two with ROOL.

What the machines have in common is 5.29

I have just tested shareFS on 5.28 and it works. This is using the same version of shareFS (3.60)
So the problem has been introduced in 5.29
which accords with my experience. I switched all machines to 5.29 after Christmas and that is when the problem started. Looks as if it needs to be sorted for 5.30.

I’m curious, would differing netmasks cause auto updating not to work only occasionally, or all the time? When I’ve seen it in the past, it’s worked fine eg. all morning, then suddenly creating a new folder appears not to work, but when you look on the remote machine, it’s there!

Incorrect netmasks can prevent the ShareFS updates being received by certain machines as they aren’t classed as being on same subnet for UDP broadcasts, although packets sent directly between them will be ok. That would be expected to affect things all the time, unless there is much weirdness.

So the problem has been introduced in 5.29

First version of 5.29 was October 2020, so that’s 28 months of updates to check and home in on a specific change.
I would suggest that a binary elimination would be fastest – i.e. first check the half way stage (Dec 2021) then the halfway point in the earliest half that has the fault, repeat, repeat…

I think 5(five) repeats should get you there.

When I said ‘recently’ in the initial post, I should perhaps have said I’d noticed this only in the last couple of weeks. Unlike John, I have been using many versions of OS 5.29 over months, so I think the problem has arisen very recently, perhaps only since the Pi 400 has been running 5.29 (14-Feb-2023). I characterised it as ShareFS’s ‘reluctance’ to indicate that the symptoms were intermittent.

For example and annoyingly, I cannot demonstrate the effect this morning, so maybe a reboot of the Pi 400 has cleared some as yet undetected interference with ShareFS rather than it being in isuse with ShareFS itself?

annoyingly, I cannot demonstrate the effect this morning, so maybe a reboot of the Pi 400 has cleared some as yet undetected interference with ShareFS rather than it being in isuse with ShareFS itself?

It is persistent over reboot on three different machines here with different levels of OS dating back to a year ago.

Pi3B 5.29 05 Feb 2023
pi4te 5.29 20 Jun 2022
ARMX6 5.29 01 Feb 2022

Now I begin to suspect it might not be the OS, but rather something that has crept in from HardDisc4, as I updated the three machines disk components when I put the new OS in.

rather something that has crept in from HardDisc4

Which hard disc image have you used , is it the 5.28 one and did you use the built in scrip within that download to update your !Boot.

Is it one of the latter beta hard disc images and if so you may need to be aware that recent builds introduce some issues due to a lack of SharedCLibrary 6.19 being present in the earlier ROM’s.

You also run PiHole I believe so does eliminating this have any effect?

You also run PiHole I believe so does eliminating this have any effect?

PiHole is innocent here as it has not been running since a power cut fried the SD card. Haven’t got around to buying a new card yet.

Doug – are you seeing the ShareFS problem on any of your machines?
From the above thread I know that Bernard and Rob see it but don’t know if anyone else does.

I can confirm that with OS5.29 (09-Mar-23) on both the Titanium and RPi4, both using the ROOL Inet stack, then using ShareFS changes made directly on the remote machine are not seen in the ShareFS window on the source machine. With OS5.28 on both changes are reflected back.

OS5.29 ShareFS 3.61
OS5.28 ShareFS 3.60

I can confirm I am seeing the same issues.

Create a file on a remote machine via a Share window , view it on the other machine and then change it’s name and on the first machine the name remains the same in the ShareFs window even after doing a refresh.

Select the file in the ShareFs window and try to rename it and error pops up and says it can’t be found and then the ShareFs window updates to show the renamed file as it was renamed on the remote machine.

One 5.29 – (20-Nov- 22 and the other 5.29 (5-Feb-23)

Both have ShareFS 3.61

Both have ShareFS 3.61

That is the problem, softloading ShareFS 3.60 over OS5.29 fixes it.

Thanks – we are all in this together!
You don’t need two machines to test for the error.
Share your RAM disk – menu on icon bar RAM >Share >Unprotected
open RAM and shared RAm from Discs.
You now have two filer windows:
Share::RamDisco.$
RAM::RamDisc0.$
files dropped into RAM::RamDisc0.$ do not show in the other filer.

Here was test Pi ROM. Download removed when the issue was fixed in ShareFS 3.62.

It is an up to date Pi ROM but with ShareFS 3.60.

As a bonus it also has Menu 0.40, 0.41 has an issue described elsewhere in this forum.

To show this is an irregular issue the OS version as shown in ‘Info’ from the TaskManager iconbar icon is red, just as a reminder.

ShareFS 3.60 needs to be on the remote machine.