ADFS Image Filing System?

Has anybody ever written an image filing system for ADFS format images?

FCFS can create ADFS images but they are read only.

https://www.craig-wood.com/nick/riscos/fcfs/

http://www.monesi.com/sergio/archives/fcfs110.spk

Hmm. Shareware, closed source, and 25 years old. I might try contacting the authors in a couple of weeks.

Thanks, though.

Do mean something like ADFFS (for RISC OS)?
https://www.jaspp.org.uk/forum/viewforum.php?f=9&sid=d4cbdfe10650f42be4f4821f270591ad
or Disc Image Manager (for Windows/macOS/Linux)?
https://www.geraldholdsworth.co.uk/index.php?link=DiscImageReader
https://github.com/geraldholdsworth/DiscImageManager/releases

Thanks for those! https://github.com/geraldholdsworth/DiscImageManager looks like it will do very nicely, in particular.

Has anybody ever written an image filing system for ADFS format images?

FCFS is the only RISC OS option I am aware of, but I was unsuccessful to contact Nick Craig-Wood in recent years.

I have developed a piece of Java code named “FilecoreImageReader” which is similar to Gerald’s DiscImageManager (previously known as DiscImageReader). I can provide you with a test version if you are interested – I am aiming for a dual-release this year, a basic version open-source and for-free, and a commercial version with a lot of cool additional features (partition support for harddisc images, file browser for HostFS in addition to filecore images reading both as tree-based explorer-like and filer-like, export as ZIP or ISO, direct viewing of various native RISC OS formats like Arc, ZIP, Sprites, tokenized BASIC, StrongHelp…).

There is also Python code by David Boddie available, I think it can act as a FUSE fs on Linux, but IIRC it was restricted to plain D/E format floppy images.

And there is a Linux “ADFS” implementation by I think Phil Blundell, but again D/E format only restricted to floppy images.

All of the offerings are currently read-only.

but I was unsuccessful to contact Nick Craig-Wood in recent years.

I did, about a decade ago, but unfortunately the code was part his and part Sergio’s, with some amount of it used in something commercial, so releasing the source code wasn’t really an option.

It’s a shame, because it is bloody good at what it does. But, alas…

Disc Image Reader was read only. Disc Image Manager is read and write.
ADFFS is an option for RISC OS…not sure if it is writable though.

Disc Image Reader was read only. Disc Image Manager is read and write.

Thanks for the correction! I somehow missed that, sorry for the misinformation.

I’m surprised that it’s not almost a trivial exercise, given that the ADFS code is now open source. Surely there’s a limited interface to the HAL that essentially allows reading and writing of sectors? I’d have expected it to be used for SD cards as well.

What are you actually after Simon?

Are you after an Image Filing System running under RISCOS to read FileCore based HDF images for example? If so, that’s a lot of work as it would have to recreate FileCore. For those not aware, Image Filing Systems work at FileSwitch level (ie files) and Filing System work at FileCore level (sectors)

A Filing System to read HDF is theoretically possible and a lot less coding, although I don’t think anyone has tried as it would have to overcome FileCore’s lack of reentrancy support. If not for the reentracy issue, yes it would be trivial, probably less than 100 lines of assembler.

ADFFS is an option for RISC OS…not sure if it is writable though.

ADF/JFD mounted with ADFFS are writable although it is not an Image Filing System its a Filing System – or more correctly, its a 1702 FDC emulator that parasitically attaches to ADFS’ Filing System.

DiscKnight has code to read and write Filecore discs and image files, independently of FileCore. However, it’s not in a form which would be easy to turn in to an image filing system, and would be terribly non-optimal. Plus it used to terrify me! I split the reading code from the fixing code to make DiscReader, which could extract files from RISC OS disc images on non-native systems, I never included the directory and file creation code in case anyone used it on a real disc and broke something.

FileCore’s lack of reentrancy

Isn’t an easy way to do this to implement an ADFS-HDF filing system atop FileCore? Double-click on an ADFS-HDF typed object on your disc to mount it under ADFS-HDF::madeupname.$. Not as good as having an image filing system that you can see its contents attached at the correct point in the tree, but better than nowt.

[Also, isn’t there still an ADFS driver in the Linux kernel? I did bleat when someone threatened to take it out the other year.]

to make DiscReader, which could extract files from RISC OS disc images on non-native systems

That could be pretty useful if it could run on, say, Windows (XP!) ¹ and allow access to the contents of SD card images.

¹ My use case. Sane people would probably want Linux or MacOS.

I’d love to be able to make Disc Image Manager access an SD card, but I’m just not sure how to go about doing it. It’s likely to be different on different OS and at the moment the same code is used to compile for Windows, macOS and Linux.

On Linux you just read from the SD card’s device file, the same with Windows although the filename is a lot less obvious. I’d imagine there is a device file on MacOS too.

That could be pretty useful if it could run on, say, Windows (XP!) 1 and allow access to the contents of SD card images.

I’m working on it…you will need a version of Java old enough to run on Windows XP, which will be Java 7 IIRC, but since I had that use case in mind from day 1, my code is compatible with Java 7.

Java? Mine is in C, although I could do a Python port for a laugh.

Are you after an Image Filing System running under RISCOS to read FileCore based HDF images for example?

With the obvious problem of the 4 GiB limit on RISC OS for image filing systems.

Java? Mine is C, although I could do a Python port for a laugh.

My main goal is to provide a good user-friendly and powerful UI, so Java is the obvious cross-platform choice. The low-level part of accessing filecore with Java’s insistence on “everything is signed” was certainly not the fun part, but I already had a minimal support lib to handle those things from long time ago when I created “Isofier”, an ISO9660/Joliet image creator.

Isn’t an easy way to do this to implement an ADFS-HDF filing system atop FileCore?

That would create the circular reference I was referring too as FileCore will be called when the filing system is touched; I believe the call chain would something along the lines of:

Touch ADFS-HDF::0.$ —> FileSwitch —> ADFS-HDF_DiscOp —> FileCore —> ADFS-HDF DiscOp handler —> OS_File —> FileSwitch —> SDFS_DiscOp —> FileCore

Completely avoiding the usual circular call to FileCore in ADFS-HDF_DiscOp might work although I have a nagging suspicion FileCore still gets involved somewhere in the call chain.

FileCore still gets involved somewhere

Yes, but they are separate instances of the module here.

I do have some (very limited) Python code which I use to mess around with SD cards on Linux. It handles the E+ format (only).

https://github.com/c-jo/adfs-tools.git

Explore.py will let you nose around filecore disc.

Yes, but they are separate instances of the module here.

My thoughts exactly: is the re-entrance issue a global one or limited to the same instance? In the later case, creating a FileCore based image filing system, should not be a problem.

My thoughts exactly: is the re-entrance issue a global one or limited to the same instance? In the later case, creating a FileCore based image filing system, should not be a problem.

“Global” as in “For the base filecore instance” or “global” as in “state held somewhere on system level” (zero page?)?

If it is “just” in FileCore%Base, the pragmatic solution would be to duplicate the module as FileCore2 specifically for a FileCore Image Filing System.