USB files on Pi and VRPC

Nota: FCD if the filetype for FileCore hard disc images. Just need to adapt existing tools to format and mount them.
The excellent ArchiEmu comes with tools that can format files as filecore images.

Of course, the best solution would be to have tools to make and mount filecore image files.

There is, sort of.

http://www.craig-wood.com/nick/fcfs/

Sadly, not 32 bit…

http://www.craig-wood.com/nick/fcfs/
Sadly, not 32 bit…

Just maybe, if you asked nicely, there is source available.

Of course, the best solution would be to have tools to make and mount filecore image files.

I’m a bit lost in all these different image file possibilities, but is there any mileage for Steve in ISO images? RISC OS 5 can read them natively now, and CDVDBurn will write them.

All off the top of my head, as my Iyonix with the DVD writer is still in France with my copy of CDVDBurn.

What is wrong with StrongHelp?

To add a little to the quote Steve F has kindly put up. During directory enumeration StrongHelp would return an offset as the ‘where to continue’ value. This is normally fine but not when deleting objects as the object the offset points to will be moved down. As a result a number of objects are skipped and hence not deleted.

Fixing the problem was interesting as FilerAction does not use the ‘where to continue’ value on subsequent calls but something like: n1 = n0 - d (where n0 = last ‘where to continue’ value and d = number of objects deleted in this pass).

The reason for this is, as a bit of digging showed, the way in which FileCore numbers its objects during enumeration; on each pass it simply starts at 0.

StrongHelp now uses the same scheme as FileCore so deletions should work ok.

Important anyone wanting to implement a (image) filing system that FilerAction may act upon will need to take the above into consideration!

I do not use a very up-to-date version, but I have been deleting files without trouble for years.

The problem only shows up when there are enough objects to require multiple passes. As FilerAction asks for 20 objects at a time you need to delete more than that to be sure to see it.

In case of doubt, I am not serious about using it for my current problem. ;-)

Yeah, I’d cottoned on to that hence the smiley in my reply. :-)

Fixing the problem was interesting as FilerAction does not use the ‘where to continue’ value on subsequent calls but something like: n1 = n0 – d (where n0 = last ‘where to continue’ value and d = number of objects deleted in this pass).

The reason for this is, as a bit of digging showed, the way in which FileCore numbers its objects during enumeration; on each pass it simply starts at 0.

Curiously, the description of OS_GBPB 9-12 in the original RISC OS 3 PRMs half states this “fact”; it’s only in more recent editions that clear warnings to treat R4 as opaque have appeared. FilerAction’s behaviour is in direct contravention of the modern PRM; I wonder if it was actually valid in terms of what Acorn intended the interface to be when it was written (that intention being scuppered by the arrival of third-party FSs that didn’t treat the offset in the same way)?

@David

Of course, the best solution would be to have tools to make and mount filecore image files. Then, it would be also possible to read ROOL USB/SD images directly. And perhaps even to use DiscKnight to check them.

Image file <> Real disc.

@Rick

AFAICT FCFS is essentially a create and read-back system. It is does not do file writes as it stands.

@ John

is there any mileage for Steve in ISO images?

It is a possible option, but might be more elaborate than needed.

Is this correct?

• a USB stick is a disc formatted as Fat32

• it is accessed in RO5 via Fat32FS, which is a filecore system and files are stored with true filetypes etc.

• VRPC can only see a USB stick as Fat32 and filetypes are inferred from a comma-separated suffix.

• there are no images involved

• any file stored inside an image file that supports filecore will have its filetype etc preserved

• there are number of image filing systems that might suit, but none meets my exacting requirements ;-)

Were TBAFS still developed and supported, that might be a good choice.

@ Fred

Yeah, I’d cottoned on to that hence the smiley in my reply. :-)

I knew you knew, but I was not certain of anyone else. ;-)

Image file <> Real disc

Since writing that I have been reading the PRM, and that is not the case for the DOSFS documented there, which treats a whole floppy as a file object. I do not know how that relates to the current versions of DOSFS.

Since writing that I have been reading the PRM, and that is not the case for the DOSFS documented there, which treats a whole floppy as a file object. I do not know how that relates to the current versions of DOSFS.

That is because FileSwitch is quite clever. FileCore knows what discs are in what drives. ADFS (etc) knows how to physically access the hardware. FileSwitch can point at a floppy disc (known by FileCore, handled by ADFS) and say “this is a file” and translate image reads/writes into something applicable to a disc (sector ops). In this way, the ImageFS needs only deal with an abstract “image” view of data, not get hung up with what is and isn’t a disc.

PRM 2-323 (DOSFS chapter) explains how it all files together.

Generally speaking, a physical disc is not the same as an image. Image filing systems can blur the lines, but how much blurring happens depends upon the hardware support. Is there an emulator that will allow DOSFS in the emulator to get ADFS in the emulator to mount a real physical FAT floppy disc? VRPC, I think, can. The others?

it is accessed in RO5 via Fat32FS, which is a filecore system and files are stored with true filetypes etc.
VRPC can only see a USB stick as Fat32 and filetypes are inferred from a comma-separated suffix.

Both correct. That’s why you should use a FAT32 image file and not a FAT32 disc. The USB stick (FAT32) is just here to transfer this image.

3 simple steps to create a valid FAT32 image file:
1/ Create
2/ Fat32Formatter
3/ Give the correct filetype: fc8

Then click and use.
DOSFS will be enough for small images.

PRM 2-323 (DOSFS chapter) explains how it all [fits] together.

Yup! that’s the chapter I read, in some detail. ;-)

VRPC can mount an old floppy drive (not a USB one) as ADFS and through DOSFS, a DOS disc. At least, that is how I understand it, and I still have a portable XP machine that can do it.

That’s why you should use a FAT32 image file and not a FAT32 disc.

That rather defeats the original aim.

AFAICS a FAT32/DOS image file is created with a fixed size; I used them many moons ago with PCEm. Other image filing systems change size according to the contents, which is more convenient.

Ideally, I want a image filing system that will work within VRPC to read native USB mounts. I do not think that is going to happen.

In that case, a non-compressed image file is quite feasible and just needs to have a name with the correct filetype suffix for HostFS.

There is no completely appropriate system that I know of, but I have yet to hear whether ArcFS is a supported candidate.

Of those systems that I know of – including a handful from the distant past not yet mentioned and certainly not 32-bit – SparkFS Zip or Spark files are the most proven, but do not have Rename; TBAFS is the most convenient, but is not now supported, or is it?

Thanks for all the suggestions.

SparkFS Zip or Spark files are the most proven, but do not have Rename;

I guess you can workaround this limitation by copying the file as the new name and then deleting the original.

As I said much earlier, I once had an alias to do this, but it is not entirely satisfactory.

That rather defeats the original aim.

You copy your image file on the usb key, as an archive, non compressed with all file operation permitted (even rename). Where is the problem? That’s a perfect and portable solution. Works the same way with real computers and RPCEmu (dosfs is not hostfs). Just need to set the fc8 filetype on the image file (1 file) each time. Not a big deal.

Curiously, the description of OS_GBPB 9-12 in the original RISC OS 3 PRMs half states this “fact”; it’s only in more recent editions that clear warnings to treat R4 as opaque have appeared. FilerAction’s behaviour is in direct contravention of the modern PRM;

It looks like deleting stuff whilst the enumeration is still going on isn’t something that Acorn considered when they designed FileCore as the numbering scheme is not up to it (you have to make assumptions to make things work).

This of course begs the question why FilerAction was written the way it is, why not collect the objects to delete during enumeration and then delete them afterwards? Because this could might take up a lot of memory on large directories?

I wonder if it was actually valid in terms of what Acorn intended the interface to be when it was written (that intention being scuppered by the arrival of third-party FSs that didn’t treat the offset in the same way)?

Well, that might be why but it doesn’t explain why the PRMs are completely silent on the matter, at least I’ve been unable to find anything.

There’s nothing on how applications should delete multiple objects from a directory and whether this can be safely done whilst enumerating, nor does it explain how (image-) FSs should cope with deletions during enumeration.