Rick's b.log - entry 2026/03/08

ShareFS for Linux (and Mac, and Windows)

As a side quest, Paolo found the time (how? what am I missing?) to reverse engineer the ShareFS RISC OS native file sharing protocol (having sadly gotten nowhere at all when asking about the actual source code), and he has made his own server in Rust. It is fairly platform agnostic, so there are currently no less than seven builds: Apple Darwin (ARM and x86), Linux (ARM and x86), FreeBSD (x86), and Windows (x86 and i686 which I guess is "the 32 bit one").

I am using v0.1.2, an early test release, and I have created three shares:

• "HomeDir", path='/home/rick' (my home directory), read only
• "ExtraSpace", path='/media/rick/ExtraSpace' (the SD card), read only
• "FTPdrop", path='/ftp' (the FTP server root), read/write

Let's make three things extremely clear right from the outset:

1. There were problems, some of them show stoppers.
2. ...but that doesn't matter as this is a test release, the whole point is to shake out the quirks. And, god knows, interfacing the peculiarities of RISC OS with anything else is going to be a whole pile of edge cases and oddities.
3. And, finally, let's be real here. To go from an idea to working code in such a short length of time, as a side project, while dealing with a much larger project (Merlin), the job that pays the bills, and family commitments is frankly astonishing.

Now, without any further ado, let's dive into this.

Installation was exactly as easy as Paolo said it would be. That is to say, unzip the files, edit the configuration to give it something to serve (there are actually a lot of settings, but best leave those at the defaults for now), and then...well...just run it.

So I just ran it:

Here you can see my usual shares, some from the older Pi2, the 3B+ serving itself, and then the three from my Linux machine. I have no idea what logic determines the different icons, as "Pi2Public", "Pi2Site", and the new "FTPdrop" are the only writeable shares.

Clicking on HomeDir puts the share on the iconbar. Clicking on that then opens the contents of the share.

There are three things to note here. The first is that sometimes things may be missing. When I first ran the server yesterday, I was missing "Downloads" and "Pictures", however since tidying up a the home folder they now appear.
However going into those folders... "Downloads" shows 41 files (reality is 644) and "Pictures" shows 39 (reality is 124).
My current home folder claims 32 items but there are a few more (I'll get to this), whereas yesterday it would have had around 50. I'm wondering if things start getting forgotten if there are more than around 45ish files?
Wait... is this perhaps anything to do with the old-fashioned 47 files-in-a-directory limitation in FileCore? Is some aspect of that lurking in ShareFS?

The second thing, look at where the mouse pointer is. "forblog" and "forblog".
This is what's really happening:

ick@Rick-E200HA:~$ ls
'ai songs 2025 booklet.pdf'     forblog.html         radiosettings.json
 Arduino                        forblog.html~        ShareFS
'BBC Micro startup sound.ogg'   gbDocEditorQt5.ini   sysinfo.txt
 ClearRecents~                  gsettings.txt        Templates
 ClearRecents,FFF               hints.txt            tic_opto
 ClearSwap                      hints.txt~           Videos
 ClearSwap~                     Images               weathersettings.json
 ClearThumbs                    LMon                 XedZap.xml
 ClearThumbs~                   Music               'yearly review 2026'
 Coding                         MyBackdrops         'yearly review 2026~'
 Desktop                        Pictures             zaplike.xml
 Documents                      PiVNC                ztidyup
 Downloads                      Public
rick@Rick-E200HA:~$ 

When GEdit (or is it Xed?) makes an automatic backup of a file, it simply copies the file with a tilde affixed to the end and this then makes this backup file hidden. Linux doesn't actually have a "hidden" attribute, it does it either by prefixing the name with a dot (like .config or .local) or by suffixing it with a tilde (the convention for backup files). Even on Linux this isn't entirely consistent - as I have the file "ClearThumbs~" which is a backup of the script to clear the Nemo thumbnails (a brute-force way to force thumbnails to be recreated if they were noted as having failed). In Nemo, any file ending with a tilde is hidden. On the command line they are shown, but the darker colouring of a file that is a backup only works if the tilde is at the end of a file extension, not the filename.

This can be problematic as the ShareFS server strips off the extensions to use types, as is the RISC OS way, but it can come unstuck if there are then two files with the same name - which one to use?
The server correctly notices and omits the dot-prefix files. It just needs an extra bit of code to also omit the tilde-suffix ones too.

And, then, you'll note that the filetypes are pretty much "everything is text". I could have sworn the "forblog" file had an HTML icon yesterday, but I wasn't paying that much attention. Today everything is a textfile.

So I opened the "Music" directory and then looked around. The stuff copied from my phone... I didn't look too closely, but it seemed to be, again, about forty or so files instead of the expected six hundred or so.

In the cache of files I used to make my CD, everything looked good.

I wasn't able to directly play anything because it looks like DigitalCD requires file types to be set, it won't try to guess what a file is by looking at the header.
The first file I copied... failed.

Note the oddity with the filename. What looks like a regular apostrophe to me is clearly not a regular apostrophe. The ~2019 is the Unicode value for "U+2019 RIGHT SINGLE QUOTATION MARK". It looks like the conversion isn't quite working correctly in both directions. This is a known issue.

Now I feel it is only fair to take a moment to rant at the utter lack of attention paid to UTF-8 and Unicode within RISC OS over the past twenty-odd years. The Wimp API has absolutely no concept of character set, and indeed it isn't even possible to flag "this is UTF-8" because there are no flags. Various bits of Wimp functionality is enabled (or not) depending upon what Wimp version number you claim to recognise. It was a dumb idea in 1992, and it's still a dumb idea now.
I have, for a long time, said that it would make the most sense for FontManager to treat everything as UTF-8, and to fall back to whatever the configured character set would be if it encountered something that it didn't recognise as valid UTF-8. This, of course, was shouted down by the purists who told me that treating invalid UTF-8 as Latin1 (or whatever) is entirely the wrong way to go about it.
Translation: We speak English, this doesn't affect us, so we can do sweet sod all about it for two decades.
You see, there is - currently - NO proper valid legitimate way to develop and use any UTF-8 software within RISC OS without either changing the entire system to be UTF-8 (and breaking every 8 bit character set application) or jumping through whatever hoops to do it all yourself, which gets real painful real fast. But again, this is largely a non-issue for English speakers as plain ASCII is plain ASCII, so there was never any impetus and thus it's just yet another thing that the rest of the world has moved on to handling that RISC OS needs "special treatment" over.

Copying a different file (with a straight normal name) works fine.

After setting the type, it played in DigitalCD.
I was less successful with one of the songs ripped from that Taylor Swift CD that I bought in the winter sales. It seems that I encoded those as AAC/m4a and there didn't seem to be a filetype that meant DigitalCD was willing to play it. Oh well.

Loading files was quick and effective. Here's my QuickScope Arduino sketch in Zap.

I took some screenshots. I created a "sharefs" directory in the "FTPdrop" share and tried to copy the files across. This was when the wheels fell off.

The server had taken my file "cd/png", stripped the extension, created a file "cd" (full of null bytes), and then failed to open it because "cd" is not "cd/png".
I solved this by removing the "/png" suffix, and copying the files. The result was...interesting.

rick@Rick-E200HA:~$ ls /ftp/sharefs
cd.png    copyerror,FFF  shares,B60  writeerr,FFF
copy,B60  homedir,FFF    swift,FFF   zapcode,B60
rick@Rick-E200HA:~$ 

The first file was correctly given a 'png' extension. The rest were given that annoying comma-type suffix, either text or B60 which I'm guessing is the filetype for PNG.

My personal opinion here is that Paolo is trying to do too much and is making things harder for himself.

I would suggest, when saving (sending to the server):

• If a file has a "/ext" form of extension (the DOSFS style), then just use that verbatim, so "/png" → ".png".
• If there is no extension, but it is a known type, then create a valid extension from the known type, so &B60 (or whatever) → ".png".
• If nothing else works, then give it the comma-type suffix and let the user sort it out.

And when loading (reading from the server):

• If the extension is a known type, trim off the extension and set the type accordingly.
• If there is no extension but a comma-type suffix, use that instead.
  
• If neither, DOSFSify it and hand over the file verbatim, so "blah.conf" → "blah/conf".

The problem with handling RISC OS filetype metadata is that it is really easy to fall down a rabbit hole of "how to do this best". There is no best as essentially it's a juggling act between preserving the file type information but - important - having the files work on the host. The comma-suffix only deals with the filetype preservation, but it doesn't create files that necessarily work (notice only one of the images has the correct .png suffix). The reason the rest work is because the file explorer interrogates the file to work out what it is. If the file explorer was as dumb as the RISC OS Filer, it would just shrug and say "unknown", which it is entitled to do given that ",B60" means nothing to Linux and ",FFF" isn't even right if it did make sense, which it doesn't.

I did some other tests, but basically just variations on what I have already described, suffice to say that the quirks and problems were fairly repeatable, seemed to boil down to the same issues, but all through it the server stayed up and kept working. At no time did my hourglass turn red and count down from five slowly, which is more than can be said of the genuine ShareFS if you ask it to toss you a seven megabyte file...

These issues are certainly issues, but it is in the nature of early testing - to stress things and see what breaks. So I know it'll get better. I just wanted to share this with you today because, well, because I sat down to test the software and these are my thoughts and experiences, and I'm still impressed at how far it has come, and how rapidly.

Those of you who read my blog regularly will know that getting RISC OS to talk to anything modern is less than easy. SMB1 is deprecated. I never managed to sort out file permissions to get SMB to work on this version of Linux. But even then I had to use a third-party app because LanMan+/Omni simply weren't going to cut it. There's no Bluetooth support so I can't just toss files around. Which is why "/ftp" exists. I'm running an FTP server on my machine, and I can use FTPc on RISC OS to access it. It's old and simple, but then so is RISC OS.

I genuinely look forward to updates to this project, and want to thank Paolo for doing it, and having me be a tester.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP.
It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

David Pilling, 8th March 2026, 22:53

Go Paolo! Hmm, ShareFS seems to be a lot more than one remembers, Freeway, Access... I was wondering what is not open source. Good to be able to use ShareFS cross platform. I once tried to copy everything I have on RISC OS to something else, it was interesting how I came unstuck - incompatible filenames like con and RISC OS filenames with unusual characters.     Oh yes, absolute files, ones without a type. See "Escape from RISC OS" https://www.davidpilling.com/wiki/index.php/Escape

jgh, 8th March 2026, 23:55

I was writing RISC OS application that presented in multiple different languages way back in 1990 in Hong Kong, and it's been a running sore that I have to implement everything from scratch (well, pasting from previous code) in almost everything.    Odd that I've never noticed Merlin before, it's never come up in any of the RISC OS forums I dip into.

jgh, 9th March 2026, 16:49

"incompatible filenames like con and RISC OS filenames with unusual characters."    I've had to go through lots of interations of refinements of data transfer code between Acorn systems and other platforms for things like zip/unzip, hostfs, beebem, zxtools, etc. to try and ensure everything is as bidirectional as possible, but still end up having to implement a "-safe" option to detoxify foreign filename characters. eg basterd ZX Spectrum filename " ".

Rick, 10th March 2026, 19:02

☹️  With reference to the comment about not getting anywhere asking about source code and the ensuing discussion on the ROOL forum about this mostly throwaway comment explaining why the whole thing was reverse engineered...    ...no, Martin, your comment doesn't stand.  I am not assigning blame, I am not pointing at anybody and saying "you, BAD". I am simply stating the fact that *for whatever reason* the source code was not made available.  If you or anybody else wants to go and start talking about whose fault this is, that's on you.    As it happens, I wasn't really aware who actually owned it, maybe owns it, who-the-hell-knows it...but given how long ago all this was, it's more than likely that the problem isn't who we think may or may not own it, but who actually *does* these days (after companies merge, split, change owners, blah blah) who can say anything with authority regarding the licence.    So while this was a lot more work for Paolo to do, it's his code and his totally self-written implementation and he can put whatever licence he wants on it, something that may not have been possible with anybody else's code.     So, please, how about we celebrate 🥂 the achievement instead of taking one tiny aside and turning it into yet another mountain of rage? Think we can manage that much, huh?     (JFC...)

David Pilling, 12th March 2026, 22:29

Rick - thanks for the explanation of ShareFS source. A stupid question from me, Acorn did use in RISC OS copyright material from others.

David Pilling, 12th March 2026, 23:04

The mistake is not using AI, which says    "ShareFS source code for RISC OS is available through the RISC OS Open (ROOL) GitLab repository, as it is part of the open-source RISC OS 5 codebase. "    I now see lots of discussion on the ROOL forum...

Rick, 13th March 2026, 07:48

That's the thing. There's no bad guy, there's no ulterior motive, there's just thirty years of time gone by with much uncertainty and - to be honest - probably not a lot of interest in sorting out the tangle over something that was put to bed decades ago.  It's a shame but it's reality and there are no easy answers, and sometimes you reach dead ends.    As you can see, AI is as reliable as ever. 😉

Add a comment (v0.12) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 78614 backwards.
		UK resident	Check to verify that you are NOT a UK resident.
		Your comment