ShareFS not reflecting changes

Another way to try ShareFS 3.60 is to use the module supplied here

I found that needed to go in PreDesk which is not the best of ideas as one needs to remember to remove it!!!

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

Unless I have misunderstood it does not fix it for me.

ARMX6 with ShareFS 3.60 fails to update
4te2 with ShareFS 3.61 fails to update

This is true for local and remote.

OK so running 5.29 (12-03-23) test rom on my 4B and standard 5.29 on the ARMX6.

Create a file in Public on the Pi4B , TestView, and view it via ShareFS from the ARMX6 and see it as TestView.

Now rename it TestView2 directly on the Pi4B and it updates within the ShareFS window on the ARMX6 to reflect the update to ViewTest2.

Now put 5.29 (09-03-23) standard ROM on the Pi4b and go through the same process and it will not update to ViewTest2 in the ShareFS window on the ARMX6.

Unless I have misunderstood it does not fix it for me.

Oh dear!

It is working here between a Titanium and RPi4 in both directions, and also with the one machine shared RAM Disc test mentioned above.

OK so running 5.29 with softload ShareFS 3.60 on the ARMX6 and 5.29 (12-Mar-23) on the Pi4b with ShareFS 3.60 in ROM.

Create a file TestView on the ARMX6 in Public and then open up a ShareFS window on the ARMX6 for the HardDisc image and can see the TestView on the same machine.

Go to the Pi4 and then open up a ShareFS window and can see the TestView file.

Change the files name to TestView2 in the ShareFS window on the Pi4b and then look at the the file on The ARMX6 through the ShareFS window and it does not update even with both systems now on ShareFS 3.60.

It seems that changing file names via ShareFS is the issue as done directly I get the file names to update as described earlier.

More to this than meets the eye.

More to this than meets the eye

OK so repeated the tests with the Pi4b to Iyonix and if both have ShareFS 3.60 on then it works.

Repeat the tests with PI4B, Iyonix and ARMX6 and it is always the ARMX6 that fails to update it’s ShareFS window even if it has ShareFS 3.60 on it.

I can manage to see the updated file name in the ARMX6 ShareFS window if I select the file and go to rename it and once the resultant error message saying it can’t find the file is cleared then the view is updated with the correct file name.

So as the ARMX6 has a ROM dated 20-Nov-23 and the other two have ROM’s dated 9th – Mar -23 then I conclude that perhaps there is a filer issue in the ARMX6 ROM in addition to the ShareFS issue that all three have that has clouded the testing.

So basically I failed to do what any good tester would do and make sure there is a consistant base to work from!

I can’t update the ARMX6 ROM to a later version as the beta available here on the ROOL site is still a Nov22 one.

If anyone can supply a later ARMX6 ROM then I am happy to test it.

An i.MX6 build from today’s source code tarball was here, removed pending formal fix. (I don’t know why ROOL’s own build has got stuck in the past.) My build is regressed to ShareFS 3.60. It is very untested, I don’t have an i.MX6. Is a build from ROOL sources actually the same as an RComp build?

ShareFS filer windows updating remains good here with ShareFS 3.60 but that is only with the Titanium and various Pi’s. The one sure fire way to mess it up is to softload ShareFS 3.61. However there might yet be more to this than simply the ShareFS version.

Status of my machines:

1. Pi 4te2  ShareFS 3.61  update fails
2. Pi 3B    ShareFS 3.60  update fails
3. ARMX6    ShareFS 3.60  update fails

I will put ShareFS 3.60 on the Pi 3B and test.

Right this is getting really messy as after doing some more testing things got in a right state on my ARMX6 so I recovered it back again to a stable setup.

David I have decided not to try the updated ROM for teh ARMX6 yet until I feel a little braver.

So I started from scratch again on the testing.

All machines on a version of 5.29, Iyonix and Pi4B 9/3/23 and ARMX6 20/11/22.

All three systems hard disc image updated to the latest build 9/3/23.

All systems initially running the ROOL internet stack and ShareFS 3.61

All machines sharing thier Public directory via ShareFS and each making sure that the host machine also has an instance of it’s own public directory showing in a ShareFS window.

i.e ARMX has ShareFS windows showing Pi4B , Iyonix and ARMX6 named in the title bar Share::.$

Create a blank Testview named directory placed in each Public directory on each machine directly.

On the ARMX6 alter the name of the TestView directory in the ShareFS window for the all three systems , including it’s own instance, and it fails to update on the remote machines.

On the ARMX6 alter the name of the TestView directory in its own Public directory directly in the filer window and it also fails to update.

Repeat the exercise on the other two machines and again no update.

Install ShareFS 3.60 in the Boot.Choices.Boot.Predesk on all three machines and reboot and again set up up as above.

Repeat the exercise and all three machines show the updated directory name including it’s own instance of the directory in a ShareFS window.

Now install ROD’s 7.03 Internet stack and reboot on the ARMX6 and Pi4B.

NB It doesn’t seem to work on the Iyonix yet.

Repeat the exercise and for the machines running the ROD stack if you alter the name of the TestView directory in Public via the remote machine then this is not reflected back in the ShareFS window on the host but is shown in the direct filer directory view on the host.

i.e on the ARMX6 you have ShareFS::.Public.$ showing as well as SCSI::.$.Public showing and only the later reflects the up dated view on the remote system in this case the Pi4B.

So it seems that there is an issue with ShareFS 3.61 and that ShareFS 3.60 clears this up unless you have updated the Hard Disc image to a later build and are running the ROD 7.03 stack.

It seems, to me, the issue is being rather complicated by have a two network stacks plus the changes that ROOL are doing with also the lack of a simple way of reverting Hard Disc image updates not helping.

Roll on the ability to use Packman to update/revert the had disc images unless of course you have a machine that is tied to a particular build from another supplier other than ROOL.

So to keep it simple I hope:

ShareFS 3.61 fails to update
ShareFS 3.60 does update if using the ROOL interet stack
ShareFS 3.60 fails to update within a ShareFS window running on it’s own machine when either changed remotely or via the filer window on it’s self if using ROD’s 7.03 stack and later disc builds.

What was that thread elsewhere here on testing all about :-)

ShareFS 3.61 fails to update
ShareFS 3.60 does update if using the ROOL interet stack
ShareFS 3.60 fails to update within a ShareFS window running on it’s own machine when either changed remotely or via the filer window on it’s self if using ROD’s 7.03 stack and later disc builds.

It’s probably time someone told ROD

It’s probably time someone told ROD

I think it is best to resolve the issue with ShareFS 3.61 first and then we have a fixed base and then inform ROD if there is still an issue with their stack as we are assuming that 3.60 has no issues of its own….

Just think… if this thing was open source like most of the rest of the OS, one could drop in debugging messages to trace what’s actually going on…

While I cannot say I’ve ever used a share locally (strikes me as odd given its files right there on the machine), I do run ShareFS between the Pi3B+ with an OS dating from… about Juneish but I’m not sure if it’s last year or the one before ¹² and the ROD stack, and the Pi2 with an OS from God knows when ³ and the ROOL stack.
The 3B+ is R/ and the 2 is RW/.

Haven’t noticed any inconsistencies, but then I’m usually only on one machine or t’other.

¹ Storm warning, machines off, going from memory.

² I update “every so often”, but usually in response to a useful feature or bugfix.

³ But my memory fails me on this. It’s new enough that it fails to shut down (that Clipboard bug), but that’s all I can tell you.

While I cannot say I’ve ever used a share locally (strikes me as odd given its files right there on the machine)

It is just to simplify the process. You can test for the problem even if you have only one machine.

While I cannot say I’ve ever used a share locally (strikes me as odd given its files right there on the machine)

Well as someone who did new product introduction I can safely say I’d be a Millionaire if I got money for everytime the product development team said “Why the hell did the user do that” when we feedback testing responses.

This is one of those why would you cases but it does throw up an inconsistancy so that does need addressing in some form.

The ROD Inet stack 7.03 does introduce the problem even with ShareFS 3.60. It can be seen in the one machine mode, sharing local source. It seems a little odd, the ROD Inet stack does not do anything to ShareFS. Do we really have two ways of getting the same fault? ROD Inet or ROOL Inet plus ShareFS 3.61.

Curious, I had the latest version of !Internet installed (packman-daily builds), reverted to the packman backup, ShareFS icon reappeared.

Not many things use still UDP broadcasts these days, has anyone checked they are still working on the affected stacks/machines?

Do we really have two ways of getting the same fault? ROD Inet or ROOL Inet plus ShareFS 3.61.

I can update that the local ShareFS window will update with the ROD stack and ShareFS 3.60 if you manually select the directory and then try to rename it and after the resultant message that it can’t be found the ShareFS window contents update and it now has the name of the first change.

So it seems to me as if a update message was not acted upon or sent/recieved but only on the host machine as the other machines are updated.

Any way as someone said time to get a packet sniffer out and some debug code in ShareFS to see what is happening and thats all above my grade I’m afraid but happy to test if someone supplies the requied debug stuff.

While I cannot say I’ve ever used a share locally (strikes me as odd given its files right there on the machine)

Apart from sharing between my RPi, RPC & Beagleboard…

I have Loader on uSD & HD4 on SSD. SDFS is killed because I got fed up with selecting the wrong drive so to install ROM updates I use ShareFS.

Two thoughts…

ROD internet 7 will reinitialise support modules like sharefs during its startup, as it is loading a full set of new modules (but not ShareFS). If you’re not using a ROM baked with shareFS 3.60, make double-sure that 3.60 is active after Internet 7 has loaded, not 3.61 from ROM.

Second thought…

If there is a reproduceable fault with 3.61 vs 3.60 with the ROOL stack that is in ROM, it is almost certainly better to start there, and fix ShareFS or whatever fault has been introduced. Note that when talking about ShareFS, it is also worth considering Freeway which underpins it (note that I may be muddying the waters by mentioning this).

If the problem persists, then we’ll need to issue an update to the ROD stack too, but if the problem lies in ShareFS/Freeway then we could be running in circles.

I will, of course, alert the lead programmer on the stack (Andy) to this discussion in case he has further thoughts.

Hi Andrew,

Firstly yes ShareFS 3.60 is live on the machines when the ROD stack is being used as a *Help ShareFS gives details of 3.60.

And as I said earlier I agree that the issues with ShareFS 3.61 need to resolved first as until then we don’t know if any code update will fix any issues that 3.60 has as well.

Now that it is agreed there is at least one bug, can this thread be moved to subforum ‘Bugs’?

possibly related: I have a set of BASIC applications that communicate over TCPIP. In order to establish the connection they use broadcasts. All works with RO5.29 on the ARMX6 and the rPi’s, unless I run the ROD 7.03 stack. When I run that, the ARMX6 can’t receive its own broadcasts, but can receive those from other machines, and those machines receive broadcasts from the ARMX6. The rPis work fine with the new stack.

After discussing this with ROD, I received a beta copy of TCPIP (later than the release one) which almost fived the problem.

Almost, because I was also trying the latest ROOL build of RO for the ARMX6.

Broadcasts work with the standard RO and the updated TCPIP. They work with the standard TCPIP and the updated RO. They don’t work if both are updated.

ShareFS is a major user of broadcasts. See why I suspect a connection.

FWIW I have an iMx6 running on a rom built from current rool sources within the last month.
I see the same result with sharefs3.61 on either stack,
The test: share the hard disc. open a window on the hard disc and also on the shared equivalent.
then: create a directory or rename a file in the standard scsi: disc window. it DOES NOT reflect in the sharefs displayed window. menu→refresh in the sharefs window ALSO does not show the new state of play.

This is independent of the stack in use, suggesting the issue is in sharefs, or possibly freeway.

I didn’t go as far as to get the packet sniffer out and look

and

While I cannot say I’ve ever used a share locally (strikes me as odd given its files right there on the machine)

It is just to simplify the process. You can test for the problem even if you have only one machine.

Having got the packet sniffer out, I don’t think John’s method (of viewing your own share on the same machine as the share is exported from) is a reliable test.

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. Even if the switch did do that, the MAC in the Ethernet controller will almost certainly filter out packets whose source address is yourself. Well, maybe if you were in promiscuous mode it might let them through, but neither of the RISC OS computers on my desk are promiscuous – use *ifconfig -a to see.

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.