Backup to FAT32 or FileCore formatted drive

Hi,

So currently I backup my Risc OS to an attached FAT32 formatted USB stick. So far I never had the need to restore any applications, but the day may come. Which got me thinking, are there are downsides to backing up to a FAT32 drive or would it be safer to use a native RiscOS Filecore formatted flashdrive?

Thanks,

The backside of fat is, that you lose the filetypes. It will be difficult to get it back to work. Except, you safe all as Spark-Files (zipped).
I would recommend to save Backups on Filecore formated drive.

As long as you keep a copy of FAT32FS on a RISC OS format device, you’ll be able to access your FAT32 contents with filetypes. They should only be a problem if you’re moving to an emulated system (eg. RPCemu or VirtualRPC) as FAT32FS stores its filetypes differently (metadata) to those (,xxx notation).

The workaround is to use (a series of) zips created on RISC OS with !SparkFS (etc), which will preserve the filetypes when transferred.

The only snag is that some programs don’t like running from FAT32FS discs for some reason – it might be to do with metadata, or simply quirks of the filesystem. However, if you’re just transferring data back/forth it should be OK.

I don’t know how it handles files which don’t have types (load execution address files from the pre-RISC OS era, sometimes found in old games). Those tend to be a problem whatever you use (except zips). If you’re concerned about zip performance, you could also try Tar or other rapid formats like TBAFS, but you’d want to make sure you had a copy the reading program stored for obvious reasons. Also, I think SafeStore (and others) can back up to zips directly, which might help smooth the ride.

Essentially the upside is that you can read FAT32 discs on non-RISC OS platforms. The downside is that there are the odd “gotcha”, but probably not enough to worry too much about.
Filecore USB drives will have far fewer gotchas, but require a working RISC OS system with full USB to access, so that means real hardware not emulators etc, which could be less convenient.

Andrew is completely correct (as you might expect).

FAT32 drives work perfectly well – in fact, totally transparently – with RISC OS and Fat32Fs.

The filetype problems only occur when you involve “foreign” OSs.

I have 2 such formatted hard drives in use here with my Pi(s), nominally 1/2 and 1 TB, without any problems, and have used FAT USB sticks with no problems either.

And the sticks allow file-transfer to other OSs that can read FAT also with no problem as long as you add the appropriate file extensions to allow them to be recognised, just as you would making things available via the web.

If zipping or unzipping, do it under RISC OS anyway.

Of course, if RISC OS machines no longer existed you wouldn’t be able to do anything useful with native applications etcetera – but there wouldn’t be any point anyway!

I don’t know how it handles files which don’t have types (load execution address files from the pre-RISC OS era, sometimes found in old games).

They become data files with dates in the future, loosing the load/exec information, so they do have to be kept in an archive.

The other problem with using non native filing systems is the handling of special and top bit set characters, as the mappings are non consistent and often not bi-directional. You can sometimes end up with a situation where you see two identical files from RISC OS, where as on the drive there are two files with different names which map to the same under RISC OS.

When I started backing up to first SMB and later NFS, I had to go through all my files and applications removing special and top bit characters, so everything worked correctly, which was a pain.

The only snag is that some programs don’t like running from FAT32FS discs for some reason – it might be to do with metadata, or simply quirks of the filesystem. However, if you’re just transferring data back/forth it should be OK.

Many programs have incorrect folder scanning routines that stop when 0 entries are returned instead of check that the exit register that tells them that no more entries follow. I recently fired up DOSBox mounting a FAT32FS folder and list returned by the “DIR” command was very incomplete.

Another issue is assuming the entries are sorted in alphabetic order. ROMs cannot be build on FAT32FS because of that assumption (there is a fix but it was never merged).