ShareFS not reflecting changes

Changes made to the directory when broadcast are sent out with a destination EUI48 of ff:ff:ff:ff:ff:ff and most switches (ie. the extra ports on your domestic ADSL router) don’t send broadcast packets from yourself to yourself, so ShareFS would never see it.

Does this explanation apply to the other way round? When you make a change in the shared filer window it is reflected in the “real” filer window immediately.

So, I think much of John’s non-updatey-ness with ShareFS 3.60 will be because the switch and/or MAC is preventing self broadcasts. You really do want 2 machines for this test.

And my tests were all done across three machines Rpi4, iMX6 & Iyonix and show 3.60 does work with the ROOL stack but not with the ROD one when looking at a ShareFS window on the host system for the file.

As I said earlier lets get 3.61 fixed first so it works on the current ROOL stack and then we can test against the ROD one after that.

Perhaps, something to consider: On my Pi4 I was using the daily build of Intenet from packman and the newer ROMs. Whilst testing builds from Sprow, shared on the forum, on another machine. I noticed an issue with Netsurf crashing. I wondered whether it could be related to the Internet directory located in Boot. On my main machine which uses the ROD internet stack, I removed the new Internet directory (daily build version) and reverted to the original. ShareFS is now visible on the iconbar.

> Perhaps, this is why we only need one TCP/IP stack and both parties working in a mutually beneficial way <- New thread.

You really do want 2 machines for this test.

You can test for the problem even if you have only one machine.

In a non-parallel universe probably only one of the above statements can be true.

Fact:
PineBook: 5.29 4 Feb 2022, ShareFS 3.60 7 Mar 2020, Freeway 0.41 26 Mar 2017
Shared RAM Disc. Changes to EITHER the shared RAMDisc0 filer window or the local RAMDisc0 are immediately mirrored in the other filer.

This is also true on a Pi4 with 5.28 as previously noted up thread.

So I conclude that you can test for the problem even if you have only one machine.

But Sprow said unless you are running in Promiscuous mode. I don’t know what that is but here is the result of ifconfig a :

 *ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.93 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:0e:c6:c1:ba:5d 
ppp0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST>
*

So I conclude that you can test for the problem even if you have only one machine.

Doing that. ARMX6, RO5.29, ShareFS 3.61

View RAM disc locally and over its share.
Delete a file via share window, immediately disappears in local window.
Delete a file in local window, still seen in shared window. Double-click shared view, “Not Found”.

The same test on an rpi3 with 5.29 (22Dec2022) and ShareFS 3.61 gives identical results to the above.

View RAM disc locally and over its share.
Delete a file via share window, immediately disappears in local window.
Delete a file in local window, still seen in shared window. Double-click shared view, “Not Found”.

Same behaviour here with ARMX6, RO5.29, BUT ShareFS 3.60

As noted above with PineBook 5.29 ShareFS 4.60 ShareFS working both ways.

unless you are running in Promiscuous mode

*ifconfig ecp0 promisc
ifconfig: promisc: bad value
*

How very disappointing!

#ifndef __riscos /* No changing description or user requested promisc yet */

Maybe later then.

Who owns the source to this thing? (and why’s it still embargoed after all these decades?)

It would surely be a lot simpler to debug with access to the sources.

Alternatively, has the protocol in use ever been properly (or at all?) documented?

I note that the ROD stack has pulled two closed source things out of the OS by reimplementing them. Namely Resolver and MBufManager.
This is Good.

Freeway was commissioned rather than written in-house IIRC, but Acorn used to state that “The Freeway module is copyright Acorn Computers Ltd”.

Just remembered this… https://www.riscosopen.org/forum/forums/11/topics/15216#posts-101355
Anybody with a troublesome machine and skills interested?

Changes made to the directory when broadcast are sent out with a destination EUI48 of ff:ff:ff:ff:ff:ff and most switches (ie. the extra ports on your domestic ADSL router) don’t send broadcast packets from yourself to yourself, so ShareFS would never see it.

Does this explanation apply to the other way round? When you make a change in the shared filer window it is reflected in the “real” filer window immediately.

ShareFS is a little unusual amongst the commonly used network filing systems because it is both client and server rolled into one (compare with NFS which is just a client, LanManFS which is also just a client, NetFS too).

When you make a change to something which is shared (aka “exported”, acting as a server) that change must be broadcast to any clients which have that share mounted. It must also be sent directly to the holder of that resource. So if you change Share::MyDrive.$.Test that must be sent to whoever served ADFS::MyDrive.$.Test, and once that change is made that is broadcast to all clients viewing it.

On 12-Mar JR said: “ARMX6 with ShareFS 3.60 fails to update”
On 15-Mar JR said: “PineBook: ShareFS 3.60 Changes to EITHER the shared RAMDisc0 filer window or the local RAMDisc0 are immediately mirrored in the other filer.”

You really do want 2 machines for this test.

You can test for the problem even if you have only one machine.
In a non-parallel universe probably only one of the above statements can be true.

I think both statements can be true. The key bit I was trying to explain was: not all networks will return broadcast messages to the port from which it came, and not all network interfaces will accept self addressed packets.

Given the differences you observe with ARMX6 (not working) and PineBook (working), both running the same version of ShareFS, presumably on the same network at your house, would suggest the difference in that case is because the MAC on the ARMX6 is filtering out self addressed packets, whereas the USB dongle on your PineBook is not. To be a fair test, a test from which you can draw a valid conclusion anyway, you really do want 2 machines.

Regardless of all the uncontrolled experimenting going on, the packet sniffing I did yesterday did confirm ShareFS 3.61 isn’t sending the updates out, so hopefully that narrows it down somewhat for ROOL.

unless you are running in Promiscuous mode

*ifconfig ecp0 promisc
ifconfig: promisc: bad value

For a DCI4 driver to go promiscuous you need to be a protocol module and register an address level of 3. Don’t think you can set it with ifconfig, but if it were set it appears in the list of interface flags in <CAPITALS>.

Regardless of all the uncontrolled experimenting going on, the packet sniffing I did yesterday did confirm ShareFS 3.61 isn’t sending the updates out,

Well clearly the “Controlled” testing of ShareFS 3.61 failed before it was released :-)

As I said before I have seen countless occasions where products were sent out to end users for testing that have passed the internal testing regime and failed badly when an end user tested them because simply they do things that more a thoughtful/methodical tester may not do so I would not rule out the uncontrolled things as bad.

Anyway isn’t that what releasing beta components is all about testing on real end user systems and against what end user do peronally that will vary greatly from each user to the next…

Hi

Copy of email sent to code@riscosopen.org. This is me offering to fix this.. I wonder…

It has become clear that ShareFS 3.61 has a issue with window updates that is not present in 3.60. The issue shows up with either the ROOL stack or the ROD stack in place

Test:

Open an ordinary window and a share window on the root of the disc, so you have 2 windows open, e.g. SDFS::4.root and Share::root

Change a filename in SDFS::4.root. If ShareFS 3.60 is in place then the change propagates to the ShareFS window within a second or so. With 3.61 the share window does not update.

The most recent ShareFS sources I have are 3.54 or thereabouts, so of little use in debugging a fix. Hence the request for current sources, or relevant git access, so I can sort a fix. Git access would be best so I can do a git diff between 3.60 and 3.61.

Any help appreciated

Disclaimer: I’m not a programmer or a network expert so I’m maybe missing something here.
I’ve just tried on a Pi which had no network cable connected, and ShareFS 3.60 still shows updates made to a local share after about 2/3 seconds, so other network hardware not passing particular packets back to you preventing you seeing your own updates might be a red herring?

I tried copying files by ShareFS between two machines. One has a recent RO5 and ShareFS 3.61; the other has a rather older RO5 and ShareFS 3.60. I copied in both directions. One was used headless and viewed/controlled by VNC. The copies showed up, but only after a long delay – 30 seconds or more. The delay seemed to apply equally in both directions.

I had an email from John Ballance, saying “The sharefs 3.61 issue is still there, and I have confirmed identical behaviour with the new stack and the standard rool stack.” I know no more, other than that he must have read this thread.

he must have read this thread.

See above!

See above!

Bugger. Memory failure. Again. (And again, and again…)

Re-reading it, I do remember reading it the first time…IYSWIM.

Lovely thing memory.

To reiterate-

ShareFS 3.60 reflects local updates into the SharefFS window almost immediately. (a second or so).

ShareFS 3.61 does not do this, though after a while, (I got bored with waiting), it eventualy reflected into the sharefs window.

This is INDEPENDENT of the stack in use
.
It has also been commented ‘is freeway involved’? The 3.60 test included the previous version of freeway, whilst the newer test, using a rom built in late feb, included the current version.

ShareFS 3.60 reflects local updates into the SharefFS window almost immediately.

If I want to use ShareFS 3.60 on a machine that has ShareFS 3.61, do I just RMLoad ShareFS 3.60 after boot or is it more complicated?

There is a fix in the works. As built here changes in the remote Shared source directory are reflected in the ShareFS window, and this is for both the ROOL and ROD stack. The fix fixes the two machine scenario.

The bit that still does not work is the one machine scenario with the ROD 7.03 stack, viewing a local folder via ShareFS, changes are not reflected in the ShareFS window. This was also the case with ShareFS 3.60, I get the impression others were not seeing this. The ROOL stack is just fine.

Tested on Titanium and RPi4.

For now it is standby and wait time, until a release appears.

The bit that still does not work is the one machine scenario with the ROD 7.03 stack, viewing a local folder via ShareFS, changes are not reflected in the ShareFS window. This was also the case with ShareFS 3.60, I get the impression others were not seeing this.

Yes That is what I see on ARMX6 with ShareFS 3.60 and ROD 7.03

The bit that still does not work is the one machine scenario with the ROD 7.03 stack, viewing a local folder via ShareFS, changes are not reflected in the ShareFS window. This was also the case with ShareFS 3.60, I get the impression others were not seeing this. The ROOL stack is just fine.

I think you will find that this is caused by a known issue with the ROD stack, which is in the process of being fixed – but really it’s for John Ballance to comment.

Oops, crossed in the post!

There may be two issues.

The first is in ShareFS 3.61. Inet5 has different structures and changes are needed prevent the accidental squishing of the broadcasting of share updates.

The second is that for the one machine scenario differences between the stacks may be down to how “own packets” are handled, as already suggested.

I think you will find that this is caused by a known issue with the ROD stack, which is in the process of being fixed

Testing the fix as we speak and sent results back for both a one and two machine scenario.

OK So limited testing of the latest ROM with ShareFS 3.62, PI4B, and Hard Disc image 19/3/23 shows that the failure to update ShareFS windows seems to have been sorted now.

I have tested against the latest ROOL and ROD stacks on the Pi4B and will do so against other systems when I get more time later today or Monday but it looks promising so thanks to all for their testing and also to those who provided a fix.