ShareFS not reflecting changes
Bernard Boase (169) 208 posts |
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? |
John Rickman (71) 645 posts |
I was about to post a topic – ShareFS not reflecting changes and had prepared the text when lo! Bernard had already posted it! |
Rick Murray (539) 13811 posts |
13 Feb 2023 → Freeway → Drop COMPAT_INET4 support Has this subtly broken something? |
John Rickman (71) 645 posts |
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. |
Steve Pampling (1551) 8163 posts |
John, that sounds like you’re testing locally, and therefore the issue is all in the ARMX6 and ROD TCPIP build. Or misunderstanding of your description? |
Andrew Conroy (370) 725 posts |
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. |
Alan Adams (2486) 1147 posts |
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. |
David J. Ruck (33) 1630 posts |
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. |
Martin Avison (27) 1491 posts |
If you are running QuickFiler, then F11 will refresh a Filer display. I use it with LanMan98/FS. |
Paul Sprangers (346) 524 posts |
Or just click Refresh in the menu. |
Andrew Conroy (370) 725 posts |
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! |
Sprow (202) 1155 posts |
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 Rickman (71) 645 posts |
John, that sounds like you’re testing locally, and therefore the issue is all in the ARMX6 and ROD TCPIP build. For the sake of clarity I have ruled out ROD TCP/IP stack as being at fault. What the machines have in common is 5.29 |
John Rickman (71) 645 posts |
I have just tested shareFS on 5.28 and it works. This is using the same version of shareFS (3.60) |
David J. Ruck (33) 1630 posts |
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. |
Steve Pampling (1551) 8163 posts |
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 think 5(five) repeats should get you there. |
Bernard Boase (169) 208 posts |
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? |
John Rickman (71) 645 posts |
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 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. |
Doug Webb (190) 1158 posts |
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? |
John Rickman (71) 645 posts |
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? |
David Pitt (9872) 363 posts |
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 |
Doug Webb (190) 1158 posts |
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 |
David Pitt (9872) 363 posts |
That is the problem, softloading ShareFS 3.60 over OS5.29 fixes it. |
John Rickman (71) 645 posts |
Thanks – we are all in this together! |
David Pitt (9872) 363 posts |
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. |