ShareFS2

I’d like to see a functional replacement for ShareFS, implemented across all versions of RISC OS from 3.1 upwards, that doesn’t suffer from the problems that the present ShareFS does, mainly: (1) the technical problem that some client receivers can be overwhelmed by a fast host transmitter, and (2) the intellectual property problem of non-open source.

ShareFS is very useful. The original idea of a universally available peer to peer filing system is very valuable. I wish it worked between my Iyonix and BeagleBoard.

Just playing devil’s advocate for a moment, would it be better to concentrate effort on improving the RISC OS Samba server and LanManFS?

http://riscossmbserver.sourceforge.net/

The discovery / publishing side of share fs seems to work OK, it is only the actual connection that fails.

Could ShareFS2 publish shares from RISC OS on other protocols too, and use these in preference?

(Presumably the other network FSes would need to be modified to use any such system.)

Just playing devil’s advocate for a moment, would it be better to concentrate effort on improving the RISC OS Samba server and LanManFS?

Even if it were made to work properly, it’s difficult not to lose some filetype information. And in any case, I really do mean that I want it to work on RO 3.1, so the footprint of server plus client must be small, so that even RAM-strapped computers can have room for some networked applications to run too.

The discovery / publishing side of share fs seems to work OK, it is only the actual connection that fails.

Agreed!

It was always a pain to get ShareFS working over multiple networks. It could be done, with some difficulty.

However, what I want now is ShareFS over VPN!

I agree that ShareFS could work better/ have better integration with other protocols and that its buffering/delivery protocol could be improved but I can confirm that I have it working between my Iyonix, Beagleboard and 2 RISCPC’s and that it hasn’t been an issue to date as I have set ShareFSWindow to a value of 1 and thus limited the issue.

I would also like to second the proposal to improve Samba Server as it would be useful means of sharing RISC OS hard drives with other systems.

Finally perhaps how about one simple application that handles ShareFS,Samba server, NFS etc systems in one place rather like an enhanced Omniclient but with additional server protocols as well.

Seems like I may have to consider contributing to a bounty for something like this.

Seems like I may have to consider contributing to a bounty for something like this.

It’d certainly be a great thing to have a single manager which can do ShareFS, Samba, NFS and SFTP (or FTPS or whatever it is that you do over SSH) client and server. The tricky thing about turning that into a bounty would be documenting exactly what the acceptance criteria are in order to agree when the end product has been delivered to a suitable level to make the payment.

That’s the problem with a lot of the more attractive and complex wish-list items and the main reason why we don’t have more bounties open yet. If people out there would be willing to help with the precise bounty definition, then we’d be happy to add more bounties.

would it be better to concentrate effort on improving the RISC OS
Samba server and LanManFS

[…]

Even if it were made to work properly, it’s difficult not to lose some
filetype information. And in any case, I really do mean that I want it
to work on RO 3.1

But it’d be a RISC OS SMB client talking to a RISC OS SMB server, so there would be no loss of filetype information since the native filing system at each end can preserve it and the transport (SMB) can also preserve it by putting it in the extended attribute fields.
It’s only hard when you go RISC OS <→ Windows because there isn’t a 1:1 mapping between the valid filing system characters and Windows has nowhere to put the filetype meta data.

And as regards 3.1, I don’t think it’s worth expending any effort at all on a 20 year old version of the OS. I just looked here and LanManFS has 41k of workspace and is itself 110k, which is pretty frugal.

Would be nice to see AFP and Bonjour support (Freeway is to Bonjour what ShareFS is to AFP, AIUI) too, if the relevant standards are sufficiently open. IME so far, AFP sharing and Bonjour discovery is very considerably more reliable and responsive than equivalents common in the Windows or Linux worlds. The FSEvents mechanism used by OS X can be directly compared to filer upcalls for file modification notifications, too, so you’d be far less likely to need to lean on a ‘Refresh’ Filer option, or accidentally be left with a stale view of the filesystem contents.

The FSEvents mechanism used by OS X can be directly compared to filer upcalls for file modification notifications, too, so you’d be far less likely to need to lean on a ‘Refresh’ Filer option

The SMB protocol has a similar mechanism where you register with the server to push a message to you when a directory changes, it’s just LanManFS doesn’t have any code to deal with it. The message is simple, but making LanManFS listen looked a bit hard last time I looked.

And as regards 3.1, I don’t think it’s worth expending any effort at all on a 20 year old version of the OS.

It’s important to me! I have two A3010s on my LAN; one runs my central heating and hot water, the other is its backup and test bed.

It’s important to me! I have two A3010s on my LAN; one runs my central heating and hot water, the other is its backup and test bed.

But is it important that the new system runs on 3.1 machines, wouldn’t the new system communicating reliably with them do?

But is it important that the new system runs on 3.1 machines, wouldn’t the new system communicating reliably with them do?

Look at it the other way round. A functional replacement for ShareFS should be little bigger than the original, and shouldn’t require any more from the basic OS. Why shouldn’t it be compatible with RO 3.1?

Dave Higton wrote:

ShareFS is very useful. The original idea of a universally available peer to peer filing system is very valuable. I wish it worked between my Iyonix and BeagleBoard.

It works on ours! I wonder why it’s not working for you?

I wouldn’t want ShareFS replaced! For one thing it is often able to punch straight through all sorts of Windows networking protocols when RO is being hosted on a Windows box. I’ve often resorted to running RO on two Windows machines that otherwise could not see each other over a complex network!

(Though it seems to be the case that XP<→XP, Win7<→Win7 but XP→Win7 – ie the Win7-hosted RO can see the XP-hosted RO, but not vice versa. Odd)

The two main problems (from a user perspective) with ShareFS are its tendencies to “overload” buffers – it seems to try and send larger and larger chunks until it falls over (hourglass, countdown, then error). It’s probably not quite like that technically, but that’s how it appears. We worked round it in SafeStore by regulating the chunk sizes of data, resulting in much smoother operation (one can backup via SS, where filer_copy operations hourglass and fail). It’d be nice for some regulation like this to occur within ShareFS (or is the part of Freeway), but I don’t know how feasible this is.

The other problem is lack of VPN traversal. We use Vigor routers to link offices via hardware VPN, which works fine for most things, but not ShareFS, sadly. This makes file transfer between “real” RISC OS machines tricky. It might be difficult to make it “automatically” traverse VPNs (I think the Freeway design is difficult to change in this regard, from what I was told historically), but perhaps there could be some way of telling it about valid “external” address ranges by specifying an IP address/netmask range?

Has the ShareFS protocol ever been documented anywhere? Since it looks unlikely that the module source code will ever be released, it might make sense to have a bounty to produce a free/open version which can be used as a drop-in replacement, complete with whichever fixes are necessary to stop it overloading the remote machine.

Or are ROOL able to offer people an NDA if they want to work on the current version of ShareFS?

There is source, isn’t there? I’ve reversed a number of versions over the years but I’m pretty sure I’ve seen source recently too. At this very establishment to boot.

@Andrew I’m not sure any version has ever had full support for ‘external networks’ but some support does exist in various versions. I had RiscPCs on one network talking to an emulator on a different network by nasty hackery of Freeway’s workspace. ie there was no UI but the support code IS there. VPN should be no problem therefore.

Note that I had to manually tell each Freeway of the other network, but network numbers (IP ranges) were statically defined so that was just a configuration detail.

There is source, isn’t there? I’ve reversed a number of versions over the years but I’m pretty sure I’ve seen source recently too. At this very establishment to boot.

The Freeway source is there (and the rest of the networking stack, IIRC), but the ShareFS source isn’t.

Indeed, Freeway was written by Acorn (and hence we have been able to release under the Castle licence), but ShareFS was written by ANT, and our negotiations with them have been going slowly to say the least.

are ROOL able to offer people an NDA if they want to work on the current version of ShareFS?

That is something that we have been able to arrange on a few other closed-source components to date, and I don’t see why ShareFS should be any different.