New filesystem...is it hard?

I am thinking of writing a new filesystem for RISC OS.
It will be something like !SparkFS or !TBAFS (but not for compression) rather than like IDEFS or SCSIFS.
i.e. file based, rather than block level.
Well that is at first, down the road I’d like to write a filesystem from scratch (but that’s just a sign of my general state of mind, I like to bend my mind round subjects that our minds aren’t generally supposed to do). That road maybe a long long way away, if even reachable!

Anyway! My question is how hard is it writing filesystems for RiscOS in the simplistic sense. i.e. just integrating with the filer.
My assumption is that it will not be too difficult, but it is going to be an “interesting journey” with plenty of swearing and nashing of teeth ;-)
Does this sound about right? Or is it a nightmare I’m better off avoiding at all costs.

I am insufficiently expert to give a good reply. For what it is worth Joe Taylor told me that it was not too difficult to use the Toolbox to reproduce the GUI aspects of the Filer.

There are various extensions to the Filer that I think are worth considering: user-defined attributes, hooks for greater control by applications (this would involve semaphores to avoid contention), an abstract control language mapping user-actions to filer-actions on a per directory basis (as in Riscix). I also think that more thought is needed on the right visual metaphors. For example, displaying a directory of a thousand files of the same type with names from 000 to 999 in the usual way is a nonsense – a waste of graphical effort. Other platforms have toyed with 3D effects, use of colour and decorated backgrounds to make the purpose of a directory more easily recognizable.
OK, apologies if these hares are not running into the thickets that you want to explore.

I was more hoping to integrate as a filesystem, rather than use the toolbox to reproduce the GUI aspects.
As the goal would be to save from Zap (I only use that as an example because I love it) or !Paint etc. directly into it

Just reading up on fileswitch and filecore now…

Start with an image filing system, because it does not involve handling the hardware level, too. Have a look at the various open source filing systems. X-Files, DOSFS, Memphis, raFS, LayerFS. And PRM Volume 2 is your friend.

I never wrote one myself, but always planned to do it – starting with a proper ISO9660 FS to replace CDFS, then doing an implementation of ext2 or ext3, maybe doing an adapter for FUSE FSes…

Thanks Steffen/Gavin.

I spent 30mins reading volume 2 last night, I admit whilst catching up with elementary…

I was thinking of starting with an image filing system – just didn’t know that was what they were called!

A great idea starting with ISO! The list is endless though:
ftp, ssh, ntfs, btrfs…
It would be nice to have a go at doing a btrfs filesystem though – or maybe write/assist in a new RISC OS filesystem.
To be honest I think a lot of the discussions around filesystems seem to over-reaching the needs of a filesystem on RISC OS though.
It’s difficult to remain focused and actually deliver something useful rather than messing around – or maybe that’s just me!
If I manage to get an initial FS done, I’ll start a discussion about things for a “new” RISC OS filesystem.

My question is how hard is it writing filesystems for RiscOS in the simplistic sense. i.e. just integrating with the filer.

It’s not hard, just tedious. There’s lots of FS calls, most of which you have to implement in some sense. And you won’t be integrating with the Filer but with FileSwitch or FileCore.

Having written a few filing systems I can say that it’s much easier now than it was under RO2!

There are various extensions to the Filer that I think are worth considering: user-defined attributes

Don’t forget there are two ‘interfaces’ to be considered – the Filer’s GUI, and the filing system’s API (and its underlying implementations).

For example, though RISC OS only defines 5 attribute bits many filing systems support 8 attribute bits. However, the OS_File API would seem to allow 32 attribute bits without modification, so it would be feasible to define additional functionality, but that can’t work by magic…

Regardless of the interface, the functionality is performed (ie the attributes stored) by the underlying filing system implementation, and it can only store what it has room to store, so ADFS and HostFS won’t be doing you any favours.

Many filing systems these days can actually store arbitrary amounts of additional metadata for file objects – it might be nice to have a HostFS implementation that used such metadata for RISC OS filetype instead of the ,xxx postfix that can be so problematic. But there’s no RISC OS API for arbitrary metadata for journalling file systems so that won’t help you either.

No, the only broadly useful way of implementing additional metadata is the same way LongFiles implemented long file names – a hidden file and plenty of FS-interception shenanigans.

Other platforms have toyed with 3D effects, use of colour and decorated backgrounds to make the purpose of a directory more easily recognizable.

Not just other platforms – see ColourFiler.

Wasn’t there a library that takes some of the drudgery out of FileSwitch FS implementation? That tidies up some of the tedious stuff like having to support 47 different versions of the same OS_File call but with slightly different parameters.

FUSE is an interesting idea: the FUSE API looks a bit simpler than the FileSwitch API. While a RISC OS FUSE implementation wouldn’t be in userspace, it would open the potential for easy porting of FUSE FSes. There are some interesting FSes available like NTFS-3G and exFAT.