SparkFS 1.51 bug

As delivered, SparkFS 1.51 won’t unpack ZIP archives.

• Double-clicking on a ZIP (&A91) file gives “Bad archive”
• Dragging a ZIP archive to the SparkFS icon gives the “Save as” dialogue.

Cause: SparkFS Choices has an … interesting … assortment of modules ticked (Cab, PackdDir, Tar). All other modules are unticked.

Workaround: In “SparkFS Choices”, tick the Zip module. You may also want to tick the Spark module.

That is mildly annoying for anyone using Zips. I also note the lines limit for the UU coder didn’t seem to keep its value over a restart (turns out you had to press Return as well as click Save), so have fixed that too.

Since the choices were being written inside the app directory (naughty!) this change also moves those out to Choices$Write so that any future updates to SparkFS don’t overwrite user selections every time.

Since the choices were being written inside the app directory (naughty!)

I think the original logic (tales of yesteryear last century) was that the utility was effectively standalone and portable, but yes, these days Choices: is definitely the place to be.
It does raise the FAQ – “How do I export all my Choices?”

Hmm. Think I’ll keep a separate copy of my paid version. Just in case.

Think I’ll keep a separate copy of my paid version. Just in case.

I plead guilty to having done the same.

If there are no SparkFS choices in the global !Boot.Choices then the config files within SparkFS are are read. The internal Choices file now has sensible defaults, of Spark, Tar and Zip, and etc. On saving from the Choices dialogue the save is made to !Boot.Choices which takes priority and is the one used next time.

The other three Config files, AtExit, Extensions and NoCo never had, and still don’t have, a GUI and always were, and still are, manual text editor jobs. Any changes should be saved into the priority location, !Boot.Choices.SparkFS.

SparkFS 1.51 has one useful enhancement over 1.46 in that on dropping a directory or any filetype unknown to SparkFS then SparkFS will offer to do something with it.

There is one remaining trifle in that !SparkFS’s !Run and !Boot has a user editable sections to enable filetype &3FB, ArcFSArc. It might be simpler just to enable those, and the corresponding AtExit entry, in git. I cannot think of a downside, SparkFS has been used that way for years here.

I have built sprow’s update and it is doing what it is intended to do. So thank you.

HTH.

@ Davit Pitt

Downloaded ROOL build of SparkFS last night and it’s giving issues with ZIPs downloaded from !Store (Bad Archive error)

Quit it (FS too) and load my old copy of SparkFS and everything works fine.

I think you may want to check that.

I tested it on a CM4 running RISC OS 5.29, tonight I can give it a test on a Pi 4, 3, 2 and 1 if you wish.

I’m seeing the same here with Store downloads and a few other random downloads from other sites that I’ve opened before with 1.46

Just had another look – in Choices, ZIP is unticked. Ticking it and saving choices, all is good so far. I can open the ZIPs that were failing on first testing.

I can see this problem was mentioned and explained upthread. I downloaded via Packman today and the default choices are still without ZIP enabled. Contrary to what was mentioned earlier, I’m not seeing the new choices written to !Boot.Choices – I still have no SparkFS file or folder there and the internal choices file has been updated with the changes.

I have built sprow’s update and it is doing what it is intended to do. So thank you.

I was describing, and then built and tested, the updates referred to in sprow’s post. These are currently only a merge request and as such are yet to appear in ROOL’s builds. SparkFS 1.52 will turn up at some point.

Just had another look – in Choices, ZIP is unticked. Ticking it and saving choices, all is good so far. I can open the ZIPs that were failing on first testing.

Indeed, but it’s still a bug. Let me explain:

1) in Choices comes with ZIP unticked, however it still register itself to unzip ZIPs… unless I am not smart enough, I fail to understand the logic in this behaviour…
2) When you click on a ZIP file it still tries to unzip it, but it doesn’t know how to and, instead of giving a meaningful error message, it throws an error that the zip is bad or damaged.

So, definitely a bug, no doubt it and needs fixing, unless we are expected to read “Klingon encrypted into English” language XD

I noticed the same problem under RISC OS 5.28 in RPCEmu. What’s interesting, !SparkFS works fine when it’s located in the filesystem’s root directory (in my case HostFS::HostFS.$), but when I move it to a different place, for example Apps, it starts giving me a “Bad archive” error.

!SparkFS works fine when it’s located in the filesystem’s root directory (in my case HostFS::HostFS.$), but when I move it to a different place, for example Apps, it starts giving me a “Bad archive” error.

Maybe two copies of SparkFS, results depend on which is seen first. As they say above one will have the Zip module loaded and one does not.