!IscaFS 0.18 is available - now with ext4 support

Hi everyone!

IscaFS is a RISC OS application to grant read-only access to ext2/ext3 filesystems, for example hard disc partitions or floppy discs created by ARMLinux.

It was originally written by Phil Norman and in 2004 I fixed some bugs in it.

A few days ago, in a fit of insanity, I added support for the ext4 file system to it and released version 0.18 – the source code is available at
https://github.com/marcobaye/IscaFS
and binary archives can be found in the “releases” directory.

- it runs on my old RiscPC, but AFAIK the code is 32-bit-safe
- it now supports 128-byte and 256-byte inodes
- it now supports 32-byte and 64-byte block group descriptors
- it does more error checking when mounting an image
- it accepts ext4 file systems with the “64bit” feature flag set (because current linux systems seem to set that as default by now), but it does not actually support block numbers above 2^32, so do not expect it to work with filesystems larger than 16 Terabytes.

Please test it and tell me if you find any problems with it.

Have fun,
Marco

Nice work Marco!

Thanks a lot :)

A few times over the last few years I have wished IscaFS could be brought up to date. In theory I have the skills necessary to do the job, but I was never going to find the time. I used to use it regularly on my Risc PC 20 years ago with an early ArmLinux. It’s great to see this new update – thanks Marco!

I was a little curious since the 4té2 comes with a partitionned SSD composed of a small boot fat32 partion, an ext4 partition and a fat32 partition, so I tried:

PartTool display SCSI 4

and it reported:

Error: Second partition is not a linux partition table

I have try to read my Ti Linux partition(ext4 on adfs 4) but I can not create DummyImage with GetPartns (Aemulor)… same error.

“Error: Second partition is not a linux partition table”

Yes, at the moment PartTool only supports the FileCore/ARMLinux “partition scheme” where a FileCore file system is at the start of the disc and the actual partition table is located after it, pointed to by the “Non-ADFS-partition descriptor” in the boot block of the FileCore partition.

I’ll check if I can add support for the PC/BIOS partition scheme to PartTool. In the meantime, if you want to test IscaFS, you’ll have to build your pseudo image files in a hex editor (the format is explained in the docs). The application !PartMan can read PC/BIOS partition tables and display the sector numbers.

I made a new version of PartTool, see here:
https://github.com/marcobaye/IscaFS/raw/main/src/PartTool/PartTool,ff8

• it now also supports the four primary partitions of PC-style MBR tables
• it has a new “fakepseudo” command to build pseudo image files for IscaFS just from command line arguments, so you just need to know the sector numbers where the partition starts/ends to create a pseudo image file for it.

This might do the trick for SCSIFS, IDEFS and whatnot (please test), but with ADFS on my RO 3.7 RiscPC there is still a problem left: If the hard disc does not start with a FileCore partition, ADFS does not know the correct numbers for sectors-per-track and heads (it returns a disc descriptor with both fields set to 1), and unfortunately it also does not use LBA addressing, because that flag is only stored in the boot block at &c00.
I got around all that by:

• using a separate program calling ADFS_DiscOp with the “hard disc: specify” reason code to set the LBA flag and
• using a hacked version of IscaFS that goes “if the disc record says 1 sector per track, change it to say 63 sectors per track and 16 heads”

With these two changes, I succeeded in accessing various ext3 file systems on a ~100G hard disc that did not have a FileCore partition at the beginning. But I’m somewhat reluctant to put the two workarounds mentioned above in the IscaFS module, because the “correct” way to solve this should be one of:

• creating a small FileCore partition at the start of the disc and set the LBA flag in the boot block
• fixing the ADFS module so it queries the hardware for sectors/heads/LBA and uses those values as defaults if FileCore does not find a boot block on the disc.

but with ADFS on my RO 3.7 RiscPC there is still a problem left

If you take a look at Partition Manager you’ll see how to query the drive directly.

The functions you’ll want are:
PROCadfs_IDE in FS.ADFS – which issues the ATA IDENTIFY command
FNdecode_IDENTIFY in !RunImage – which decodes the IDENTIFY response
FNIDEUserOp_ADFS in FS.ADFS – which sends ATA commands to the drive, which you might need to read/write sectors, bypassing the FileCore 2GB limit

IDEFS and SCSIFS are similarly low-level if you look at their FS file, you’ll want to look at FNadd_drives_IDEFS/SCSIFS. IDEFS uses DiscOp 3 to perform the IDENTIFY and SCSIFS uses the SCSI command REPORT_LUNS before calling FNadd_lun_SCSIFS to query the device via SCSI_Initialise, issuing START_UNIT etc if the drive isn’t ready.

If you take a look at Partition Manager you’ll see how to query the drive directly.

Thanks, I’ll have a look.
But I think the right way™ to solve problems like this would be to add some helper module instead of adding code for a lot of special cases to each and every application.