Coming in version 2

MultiFS: read the disc, whatever is on it

RISC OS understands its own discs and, with a little help, DOS floppies. It has never understood a modern USB stick. MultiFS does, so the drive you carry between real machines works here exactly as it is.

Not in a release yet. It is written and working in development, and is due in version 2.

Why it matters

A stick that works as it is

Your files, without a conversion step

Plug in the stick you already use and the files are simply there, in the Filer, under their real names. Nothing to reformat, nothing to copy through the host, nothing to convert on the way in or out.

A real filing system, not a viewer

MultiFS registers with FileSwitch the way ADFS does, so every application already knows how to use it. Open a document straight off the stick, save back to it, drag files about in the Filer, and set the current directory to it.

Names and types survive the round trip

Long filenames are kept in both directions, so a file written in RISC OS is the same file when the stick goes back into a PC. RISC OS file types are preserved on FAT by the convention other tools already use, so a Draw file is still a Draw file when it comes home.

The project

What it actually is

A filing system module for RISC OS, written in ARM assembler, with a filer that puts the disc on the icon bar. It registers with FileSwitch exactly as ADFS and SCSIFS do, so everything that opens a file, walks a directory or saves from an application works through it without knowing it is there. Underneath, it reads sectors through the SCSI layer. That is what makes it a filing system rather than a utility that copies files off a stick.

Its own project, which this emulator happens to carry

Nothing in MultiFS is about emulation. It talks to a block device through the ordinary interfaces, and the emulator is simply the first place it has been put to work. It is being separated out to stand on its own, and a real machine with a USB stack is the obvious next home for it. That has not been tried yet, so for now it is an intention rather than a claim.

How it works

Six decisions worth knowing about

Three readers, one filing system

FAT and exFAT share the cluster arithmetic below the directory layer and nothing above it. NTFS shares almost nothing with either: no FAT, no fixed directory, no cluster chain, and every file including the list of files is a record of typed attributes. RISC OS sees one filing system.

Long names, translated properly

A file the host calls Quarterly Report.txt appears as Quarterly Report/txt, because RISC OS separates directories with a dot and an extension with a slash, which is the other way round from the disc's own world. Once a file has its long name the 8.3 alias is retired, so there is one name for a file rather than two.

exFAT written so other systems accept it

An object on exFAT is a set of consecutive entries tied together by a checksum over the whole set and a hash of the up-cased name. Both are computed here, which is why a stick written in RISC OS passes fsck.exfat and why Windows finds the files by name.

Free space, the cheap way where there is one

FAT32 keeps a count in the FSInfo sector, used when its signatures are intact and its number is plausible, and counted from the FAT when they are not. exFAT keeps an allocation bitmap instead, which answers in a couple of seconds where walking a FAT32 stick of the same size takes over three minutes.

The medium is re-read, not remembered

The volume table is checked afresh rather than built once and trusted for ever, at most twice a second, so an icon goes about a second after the stick does and appears within a few seconds of one arriving.

It never guesses

Where the right answer is not known, MultiFS says so instead of inventing one. An exFAT file may be a contiguous run whose FAT entries hold whatever was there before, so that flag is carried through to the open file handle rather than followed blindly into another file's data.

What it reads

The filing systems, and what you can do with each

Filing system	Read	Write	Where you meet it
FAT32	Yes	Yes	What virtually every USB stick is, and the case tested against real hardware
FAT16	Yes	Yes	Older sticks and cards, through the same code
exFAT	Yes	Yes	How larger cards usually arrive, written so Windows and fsck.exfat both accept it
NTFS	Yes	No	Read, including large files and full names

About NTFS. NTFS is read rather than written, and that is a decision rather than an omission. Writing it safely means keeping the journal, the bitmap and the master file table consistent with each other, and a writer that is only nearly right does not leave a slightly wrong volume, it leaves one chkdsk cannot rebuild. So MultiFS will take files off an NTFS drive all day and will never put your volume at risk.

Commands

Asking it what it can see

The first thing to reach for when a disc does not appear.

*MultiFSInfo: the filing system, disc name, drive, capacity and free space
*MultiFSDiscs: every volume the module can see
*MultiFSFree: free space on a drive
*MultiFSDir: set the current directory to one of them
*MultiFSFind: locate a file by name
*MultiFSProbe: what happened, when a disc did not appear