ShareFS - what a bloody palaver!

I wanted to get some files off the Beagle, and it wasn’t practicable to use a USB memory device (the Pi’s USB ports are on “the wrong side”, they’re hidden behind the monitor).
Besides, both devices have network ports. I have a switch. Just pull the cable out of the PC (it is off) and pop it into the Beagle, start up ShareFS, job done right?

Wrong.

The first thing was that network configuration in RISC OS is broken. I went to the setup, Access → AUN and enabled it.
What I didn’t know was that the EtherUSB detection was an old version, so it failed to detect any hardware, and nuked all of the current (working) settings.
Why, if you turn on AUN and do not touch the TCP/IP stuff, does it mess with that? It should leave it the hell alone.
But it didn’t.

So I went into the configuration file and wrote the settings manually (giving the machine IP address 192.168.1.26 as I don’t think that’s assigned to anything). I copied it from the Pi.
Reboot – failure. Testing it by pinging threw up an error about a duplicate IP.
Okay, maybe I missed/messed something. So I used the network setup. After patching the EtherUSB detection I set up the same things and rebooted.
Same problem.
So I just set the device name (“Amaranth”) and told it to use DHCP.

It did, and assigned IP 192.168.1.26. Uh… I don’t wanna…

So, the Beagle was talking to the network. It could ping by IP and name.

It also had ShareFS on the iconbar.

Now to turn my attentions to the Pi. I didn’t dare use the network setup tool in case it buggered up the Pi’s working networking.
So I looked at the file on the Beagle, and manually copied the following:

|
| Access
|
IfThere Resources:$.Resources.ShareFS.!Boot then Run Resources:$.Resources.ShareFS.!Boot
RMFind Freeway 0.26 System:Modules.Network.Freeway
RMFind ShareFS 3.38 System:Modules.Network.Share+
SetEval Inet$KickFiler 1

It didn’t work. Turns out that those two were unplugged on my system. Perhaps the network setup ensures they aren’t? No big, *Unplug will fix that.

It still didn’t work. The modules were now marked as “Dormant”. And since there’s no available source (yet?), it’s not possible to look to see what conditions aren’t being satisfied. I notice they’re in the module chain before EtherUSB. But that’s just random guessing.

I created a file in Choices.Boot.PreDesk to kick the thing:

RMReInit Freeway
RMReInit ShareFS

Good. I now have a ShareFS icon on both machines. Now let’s just share the Pi’s drive readonly, and the Beagle’s drive read/write.

Only… I can’t. Because pretty much everything seems based upon the ADFSFiler sources, it suffers from the historic situation where drives 0-3 were floppies, and 4-7 were harddiscs, and ADFS only permits harddiscs to be shared.

So time to read the Filer sources to work out what it is doing, and then create yet another patch. This time, Choices.Boot.Tasks.__Share:

REM >Share system drive

protected% = 1 : REM 1 or 0
dir$ = "SDFS::RISCOSPi.$"
name$ = "Pi"

SYS "XShareFS_StopShare", 0, dir$
SYS "XShareFS_CreateShare", (protected% << 1), name$, dir$

A similar file was made for the Beagle, with protected% = 0 over there.

Now, finally, I had both machines capable of seeing each other, and each other’s shares.

Better yet, moving files around worked.

It was slow. Really slow. But I blame either the Beagle or the USB key attached for that. Running Manga showed it struggling to maintain a download speed of 5KiB/sec. The Pi manages 300.

Anyway, copied the files I wanted, and took the opportunity to dump a copy of some recent sources (like Manga!) onto the Beagle’s drive so there’s an up to date copy of them.

All the way through, my little 7" 1024×600 display panel performed flawlessly and was clear and readable.

Reflections: Bug fixes are required.

• The first is to the networking setup. It should only alter what you have chosen to alter, and leave everything else intact and as it was.
  Breaking a working setup because something I didn’t even look at or go into is unforgivable.

• If y’all gonna pilfer the ADFSFiler sources, please make the “is this a Winnie” check conditional for devices like SCSI and SDFS where it’s entirely possible that the main system drive is :0 (regardless of whether or not it is technically ‘removable’). The reference to the floppy/harddisc distinction is an anachronism that only makes sense with ADFS on RiscPC and Iyonixen.

• Please fix ShareFS to put the icon in the correct place, to the right of Apps where transient filesystems go (RAMFS, NetFS…).

Now to go play with kitten…

So time to read the Filer sources to work out what it is doing, and then create yet another patch. This time, Choices.Boot.Tasks.__Share:

Any reason why you couldn’t have just used:
*share <dirname> <share name> -readonly ?

Um, I’m not seeing that. I’ve got an Iyonix a ARMx6 Mini.m and a newly set up Pi 3B running ROD+4.27rc16 all talking shareFS with no problems. Turning on AUN has never messed up IP networking for me, !Internet seems to load all the modules with no having to rmreinit anything.

I’ll acknowledge your point about sharing from the iconbar, it doesn’t work on the SD card of the Pi or mini.m, but I always permanently share by putting a *share command in an obey file run in !Boot

As for speed, ShareFS is nowhere near as fast as LanmanFS or SunFish to a server, but I’ve just clocked 5 to 6 MB/s between the Mini.m and Pi 3B with larger files (both on a gigabit ethernet switch). Small files will be a lot slower, but I don’t think a 1000x slower as you are seeing.

I don’t understand your problem. For me, ShareFS just works, and very quickly too. I have it permanently enabled on all my machines.

Any reason why you couldn’t have just used:

Um, because that’s not what Filer does? ;-)

with no having to rmreinit anything.

The modules start up but rest dormant until my reinit gives ’em a kick.

it doesn’t work on the SD card of the Pi or mini.m

Device :0 right?

but I don’t think a 1000x slower as you are seeing.

As I said about Manga, there’s clearly some underlying issue. I probably ought to speed-test the USB stick. I suspect it might not be, shall we say, “entirely effective for 21st century data manipulation”?

For me, ShareFS just works,

Pi vs Beagle: Static IP just works / Needs DHCP or complains about a clash.

Beagle vs Pi: ShareFS starts / ShareFS needs a kick.

Clearly, not all machines are created equal. ;-)

Whatever, it works now. But it was about as amusing to set up as Windows for Workgroups. And about as many weird quirks too…

RMReInit Freeway
RMReInit ShareFS

I was trying to figure out the same issue a few weeks ago whilst adding the network stack to the RO3.20 ROM. I’d build a fresh Pi RO5.28 SD from the latest disk image for comparison against RO3.71 and noted !Internet was RMKilling Freeway, ShareFS and possibly another Module once TCPIP was configured.

Off the back of that I presumed the two weren’t compatible – not having ever used ShareFS before, what would I know!

From memory, Freeway / ShareFS depend on AUN. I’ll take another look into getting them in RO3.20 and remove the RMKill lines to see if it works.

The three are compatible. I used them together back in the day. You can also use them on their own, or in various combinations.

It does sound like a recent bug somewhere.