No more available space?

I had forgotten about a SWI that I had written for the RFSFiles module. Using it makes things even simpler. There is an updated AppUtils, but it is functionally the same.

There is an updated AppUtils, but it is functionally the same.

What are you using to create this zip file?

I ask because SparkFS stiffs the machine, 7za (which can extract from zip) reports it as “not a file”, only the unzip available in packman seems able to understand it.

I wonder if this might be related to the problem Clive is seeing with NetSurf?

I have done it, but with the proviso that it depends on how the ROM is compiled.

Could you elaborate please?

I’m using a Pi build of 5.23 from March 2017. High vector. Loading the RFSUtils module freezes everything.

Update: Ditto my custom (low vector) build of 5.23 from October 2017.

Update2: Ditto 5.27 from 31st August 2019.

System is an ARMv7 Pi2.

I ask because SparkFS stiffs the machine

I have at last got a NetSurf CI #5053 that works (see NetSurf or SparkFS ). It was an old version of SparkFS that caused all my trouble. It had corrupted the !RunImage file while extracting it. The self-extracting readonly SparkFS 1.44 saved my bacon.

What are you using to create this zip file?

SparkFS 1.45 12-Jun-2018. I have never had any problem with this. I have downloaded the uploaded zip and it opens just fine here.

Loading the RFSUtils module freezes everything.

There is no RFSUtils module. Do you mean the RFSFiles module? There is a very old RFSApps module on my downloads page and that is guaranteed to crash a modern machine.

There may be a problem, but RFSFiles is quite a simple piece of code and I have been using it for a very long time on all machines up to this one.

I do most things on a mini.m with RO 5.25 03-Aug-2018.

that it depends on how the ROM is compiled – Could you elaborate please?

There is information on what happens in the Manual. You have read that, of course. ;-)

The KillRomApps utility relies on the order of the linked list of files Registered by the OS in Resources. This has always started with Apps.!Alarm.!Boot up to my current version. The file following the Apps is currently Resources.BASIC.Messages, but it has not always been so. If either of those is different then the utility will probably crash.

I could be a little cleverer to determine the end of the Apps, but if simple is sufficient …

I cannot see how this should matter, but the utilities are crunched. If you want the uncrunched versions, rename the Crunched directory to something else.

SparkFS 1.45 12-Jun-2018. I have never had any problem with this.

Hmm… That’s exactly what I’m using. Downloaded twice, just in case something went wrong the first time.
Never had a problem with it before, either.

Do you mean the RFSFiles module?

<looks in app> Uh, yeah. That. ;-)

There is information on what happens in the Manual. You have read that, of course. ;-)

Yes, formatted for StrongEd. I was wondering if, also, there was something to do with how the module sets itself up…

Update: Found it.

Your Service Call handler is broken.

You appear to be trying to ‘optimise’ by reading a bit of memory from the end of a string – what is that, a null byte?

TEQ    R1, #&60       ; ResourceFS_Starting
LDRNE  R0, &00000669  ; *NOT* *WORD* *ALIGNED* !!!!
TEQNE  R1, R0

The later ARMv7 in the Pi2 (and anything with a later ARMv7 or ARMv8) is throwing an exception, which in a Service Call handler is going to go horribly wrong. And, so, it does.

Just about to try with LDRNEB (and LDRB further down).

Okay, it’s loading correctly, so let’s see if it works.

Oh, now this I like. :-) :-)

Just manually put OvationPro, Printers, and PrintPDF into a “DTP” directory (and removed them from the main window).

I can create a directory “Coding” and put easy access to CC, Link, TemplEd, etc in there.

FINALLY! (fx: shouting “Hallelujah!”)

Your Service Call handler is broken.

So it is. Thanks for that. It is not an optimisation, but the LDR address is not aligned because it follows a string in memory without ALIGN. I will correct that and upload it tomorrow for you to break. ;-)

The item loaded is a service call number for another module of mine, Basil, and it is not a byte. It was once useful, but quite redundant now. The ResourceFS_Starting service call is also there because I wanted to be strictly in accordance with the PRM. Most modules do not bother with it, which makes my efforts a bit of a waste of time.

Oh, now this I like. :-) :-)

Excellent.

I was wondering if, also, there was something to do with how the module [RFSFiles] sets itself up…

Download RFSFiles separately. The source is included.

Download RFSFiles separately. The source is included.

I lied, but the updated RFSFiles does now.

An updated AppUtils has the new version of the module.

I hope the bug is cleared. Looking back, I first wrote RFSFiles in 1998 and the only significant change after 2000 was to 32-bit it in 2004. The alignment bug has been there all that time. ;-)

Download RFSFiles separately. The source is included.

I lied, but the updated RFSFiles does now.

I suspect that since there was probably no intent to deceive, then I think you will find that the correct phrase is that you “misspoke” or possibly simply “advised in advance of reality” :)

I lied, but the updated RFSFiles does now.

I noticed last night but decided not to say anything. You probably thought you had. As Steve said, no intent to deceive, just a little omission. No big.

The alignment bug has been there all that time. ;-)

I refer the honourable gentleman to ZapObey…

Oh, this is nuts.

SparkFS, that completely hung the machine opening v0.11 across three changes of OS is now opening all of the archives without any issue.

Has the Moon changed phase? Is it happier on summer time? WTF?

???

I will correct that and upload it tomorrow for you to break. ;-)

Broke it. ;-)

First, it’s already made a big difference to organising Apps:

But I have encountered two quirks:

1. CopyApp/RemoveApp go wrong with the application “!LCWS2300”. CopyApp performs the copy and throws the error giving the command syntax. RemoveApp, on the other hand, just reports the syntax.
2. RemoveApp seems unable to remove applications that have filenames >10 characters. Examples: !OpenVector, !Otter-browser, and !SammyPrint.

I’ve not looked at the MoveApp program, I was just wondering if there was a way to AddApp directly into a subdirectory, instead of what I’m currently doing – AppApp, CopyApp, RemoveApp…?

Thanks again for this.

Broke it. ;-)

AppUtils was put together rather rapidly and I was not sure anyone would really want to use it, rather than it being a curiosity. There are some short cuts that I know I took, so I will have to be a bit more sophisticated. Can I assume the you are happy that I have dealt with the RFSFiles bug?

throws the error giving the command syntax

I have done it that way, because that is what utilities should do, I think. If you are going to challenge this more I will enable BASIC error reporting through Reporter for the next release.

applications that have filenames >10 characters

That is interesting. ResourceFS itself has never had any limit on filenames, but it is not a proper filing system. If you do not know it, there is a section in the RFSFiles manual about it.

I was just wondering if there was a way to AddApp directly into a subdirectory

Ideally AddApp would do this anyway – problem solved. Once upon a time I wrote a replacement for AddApp to do this, but decided against releasing it.

I’ve not looked at the MoveApp program

That is just an example using CopyApp and RemoveApp. I did things the current way for simplicity. I reckoned that users would use ‘Add to Apps’ in Configure and then have an Obey file to do the copying. The CopyApp and RemoveApp are separate so that CopyApp can be used with the ROM apps. An Alias can be used to make a MoveApp command and also an AddAppTo command, I think. I will have a go.

Watch this space. ;-)

Using Aliases did not work satisfactorily, so I have added *MoveApp and *AddAppTo to a new AppUtils

I have not removed a short cut or two, yet.

I cannot reproduce a problem with appnames > 10 characters. !Otter-browser went sweetly into a Network directory. I will think more on this.

Errors should now be reported as they are.

and I was not sure anyone would really want to use it, rather than it being a curiosity.

The inability to properly organise Apps is one of the “big annoyances” of RISC OS. It wasn’t a big deal back in the days of RISC OS 3.10; but since modern boots put everything in $.Apps into Apps, it does need a bit of tidying up these days.

In other words, it’s an actual useful extension, not just a curiosity.

Can I assume the you are happy that I have dealt with the RFSFiles bug?

The ALIGN issue? My Pi thanks you. It no longer get… bloody hell, just watched a crow fly by backwards. I know it’s windy out, but still…
Okay, where was it. Yes, it no longer throws an exception in a ServiceCall handler, so all is happy. ;-)

RFS 0.97 29 Mar 2020.

I have done it that way, because that is what utilities should do, I think.

The point with CopyApp was that it was doing the task, and then reporting an error. At least RemoveApp failed and reported. ;-)

Plus, it’s not quite the expected error message because the syntax was correct. Something else was happening.

That is interesting. ResourceFS itself has never had any limit on filenames,

AddApp doesn’t seem to be bothered at all by the longer filenames.

but it is not a proper filing system.

I think of it as a sort of grown up version of the Beeb’s ROMFS. ;-)

I reckoned that users would use ‘Add to Apps’ in Configure and then have an Obey file to do the copying.

I’ve written an Obey file to run at the end to do all of the non-standard manipulations (including adding all the stuff not in $.Apps).

Had to set up something to Filer_Run it so it gets invoked after the main part of the desktop boot has completed. That, and a WimpSlot of -min 1024k helps it to work, otherwise it (many calls to CopyApp and RemoveApp) aborts with “Not enough memory”.

Okay, just looked at CopyApp and RemoveApp and I can see why !LCWS2300 is failing. It looks like you depend upon the !Boot file existing. There wasn’t one. :-)

So for CopyApp, the Filer_Run at the end should go via SYS "XOS_CLI" so it can fail silently if there’s no !Boot; and for RemoveApp, look for !Run if there's no !Boot?

I cannot reproduce a problem with appnames > 10 characters. !Otter-browser went sweetly into a Network directory. I will think more on this.

It wasn’t CopyApp, it was RemoveApp.

However the latest version is behaving; so finally Apps is tamed. :-) :-)

AppUtils

I’m sure all this will turn out to be very useful, but I will miss being able to just put stuff in a directory folder in my Apps directory to hide it from the Resources display!

For example, where I’ve got two different versions there, but mainly use one – but may want to use the other perhaps sometime …

A useful “feature” I discovered all by myself!

You have found a shortcut. ;-)

I popped in that call to run !Boot because Draw and Edit would not pick up double-clicked files once moved. I have realised that doing it for everything else quite unnecessary and it will not last long. There is no need for !Run either,

I will miss being able to just put stuff in a directory folder in my Apps directory to hide it from the Resources display!

That should not be affected. Apps on disc and Apps in ResourceFS are quite different, It is the Boot process that does AddApp to all the top-level apps in the disc Apps.

That should not be affected. Apps on disc and Apps in ResourceFS are quite different, It is the Boot process that does AddApp to all the top-level apps in the disc Apps.

I think I begin to see, the Apps directory is read as usual, and the subsequent additions are added via ResourceFS.

Thank you for the reassurance!

so finally Apps is tamed

Had you been paying attention in 1998 you would have noticed my RFSApps module, which would do this on RO 3.7 and 4.0. ;-)

There is a new AppUtils which deals with a couple of those short cuts.

There is an update to AppUtils which deals with all the short cuts I know and has much better error reporting, but I have chosen to rename the commands so that they all start with App, eg: *AppCopy.