ShareFS2
Dave Higton (281) 668 posts |
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. |
Rik Griffin (98) 264 posts |
Just playing devil’s advocate for a moment, would it be better to concentrate effort on improving the RISC OS Samba server and LanManFS? |
Jess Hampshire (158) 865 posts |
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.) |
Dave Higton (281) 668 posts |
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. |
Dave Higton (281) 668 posts |
Agreed! |
nemo (145) 2529 posts |
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! |
Doug Webb (190) 1158 posts |
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. |
Steve Revill (20) 1361 posts |
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. |
Sprow (202) 1155 posts |
[…]
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. 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. |
Andrew Hodgkinson (6) 465 posts |
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. |
Sprow (202) 1155 posts |
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. |
Dave Higton (281) 668 posts |
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. |
Jess Hampshire (158) 865 posts |
But is it important that the new system runs on 3.1 machines, wouldn’t the new system communicating reliably with them do? |
Dave Higton (281) 668 posts |
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? |
Matthew Phillips (473) 719 posts |
Dave Higton wrote:
It works on ours! I wonder why it’s not working for you? |
nemo (145) 2529 posts |
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) |
Andrew Rawnsley (492) 1443 posts |
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? |
Jeffrey Lee (213) 6048 posts |
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? |
nemo (145) 2529 posts |
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. |
Jeffrey Lee (213) 6048 posts |
The Freeway source is there (and the rest of the networking stack, IIRC), but the ShareFS source isn’t. |
Ben Avison (25) 445 posts |
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.
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. |