Started 21st April 2024
In which Princess Goldilocks falls down a number of rabbit holes and indulges in some yak shaving
At the end of the Acorn/RISC OS day I have around 30GB of data (250,000 files) on a prototype Iyonix computer using its original 25 year old disc drive.
By present day standards this is not much data and I thought it would be nice to have a copy to add to my digital footprint which stands at around 1TB and is backed up on multiple discs in multiple locations.
Mind you an exact copy, no missing files, no mangled filetypes.
The Optimist
I thought I would copy everything into a tar archive file. I actually tried this. I know better, for one thing SparkFS has a 31 bit limit, archive files over 2GB don't work. RISC OS has a 32 bit, 4GB filesize limit.
Discs
One option is to get an IDE to SATA converter and take the disc drive to a modern RISC OS computer like a Raspberry Pi. Then one can make a copy on another Acorn format disc. The problem is that effectively Acorn format discs can only be read on RISC OS computers...
Surprisingly present day Linux can read Acorn format discs - out of the box. But in my experiments Linux could not read discs as big as 32GB. There are stand-alone programs that can run on Linux/Windows and read RISC OS disc images - I didn't try any, they looked like they would not work on the latest format discs. It is also possible to generate an image file of an Acorn disc using Linux and then feed the image into a RISC OS emulator (e.g. RPCEmu). But this feature seems to be turned off when the latest versions of RISC OS are installed on the emulators.
What works well, copying to another Acorn disc. What's the problem? The data is still in the Acorn world. I don't want to run another programme of disc curation.
There is the FAT32 file system, discs that Acorn can read/write which (clue in the name) work on Windows/Linux. It is little known but there are spare bits in the FAT directory which are used for storing RISC OS filetype information. But... how do I get intact data from Fat32 into an emulator. Windows will know nothing of this extra data and I imagine will not preserve it.
RISC OS has a higher resolution time stamp than Windows. It also has file 'metadata'. Files have types outside of any type information conveyed by filename extensions. In addition there are files with load/exec addresses and no type - something that comes from BBC Micro days, but I have some of them.
Networks
Acorn networking, Share FS, Access. Very good, but the destination is still in Acorn-land. Although a possibility is Acorn networking from inside an emulator - there are descriptions online - it looked complicated.
Lanman98, Omniclient, networking to Windows. Problems include the timestamp resolution, lack of load/exec file support and the existence of reserved names on Windows for devices. I struggled for a couple of days to get Windows networking to work.
The people of RISC OS had squillions of names to choose from, but no they had to pick things like PRN and CON and decorate others with a few < > characters. The network solutions handle filetypes by tacking the type on to the end of the file name following a comma - TextFile,fff. RPCEmu extends this comma notation to handle load/exec addresses.
Sunfish, Moonfish, networking to Linux - NFS. Slightly better than Windows - because there are no reserved device names.
My idea
Zip archives have always been a way of handling RISC OS files on non-RISC OS file systems. My idea was to write software that turns a RISC OS directory tree into a number of Zip files - the 32 bit limit (classic Zips also have this limit) means there has to be a limit on the size of each Zip. It is easier to control a few 10's of Zip files than 100,000's of individual files.
The program is called ArcTree and you can get it from here.
I compared the results of ArcTree with those of Sunfish. What I found is that high bit characters in filenames get changed in the Sunfish->RPCEmu route. I have no idea why. It is yet another snag.
SyncDiscs has a compare function and is useful to study results.
I discussed these problems on my mailing list. Thanks to all those who contributed to the discussion 'Getting things out of RISC OS'.
I have not exhausted all possibilities. The problem is that many of the routes took a lot of time to investigate and proved to have snags. I did try most of the above. Two approaches which might work, which I did not try, are Virtual Acorn and a hard disc backup program like SafeStore.
I also tried FTP using FTPc on RISC OS and Filezilla on Windows, but that always ended with a timeout error.
Postscript
I have been told "it should (now, as of version 2.68) be possible to use
LanManFS shipped with RISC OS 5 to preserve the full load/exec addresses"