Default Hard Disc Structure

why are those wanting to access choices wanting to access it?

Because when I delete some program I want to delete it choices and all. I do the same with windows.

Because when I delete some program I want to delete it choices and all.

I was wondering when this would crop up. The RISC OS uninstall method is a blessing in its simplicity, and a curse in that extraneous things could get left behind – such as rubbish in choices.

I still believe, given that the old 77 limit no longer applies, that it would be better to let rubbish accumulate than to have somebody who doesn’t know their way around erase stuff they didn’t mean to.

Perhaps, thinking of this, the solution is not to fiddle with Choices, but is instead to think of a method whereby an app can present an “uninstall” option that would perform exactly this sort of tidy up?

If anyone knows what the 25224 files inside C:\Windows do please raise their hand.

15,848 files adding up to 3.48Gb.

The worst bit? I’m running XP SP3 but I can’t apply updates because the C:\ SSD is only 4GB and all the <beeeeep!> has pretty much filled it up. As it is, I tore out every version of .net other than the initial one thaqt Windows itself uses. Uninstalled stuff I don’t need. Hacked the registry to move some stuff to D:. Delete all the $NTblahblah files if the machine boots two or three times without incident.
But there comes a time when you just aren’t going to get any more in…

Me! me! me!
They clog up your hard disc.

If you think that is bad, have you looked at the requirements of some iOS apps? QuickOffice is a basic but useful word processor / spreadsheet / powerpoint editor. I was looking for a decent editor for iOS, something akin to the suite that was part of the Acorn Pocketbook II / Psion 3a and it looks like QO will fit the bill. It’s an archive of 59MB¹ which expands to consume 100MB¹ just doing nothing at all. I had been using Google Drive in offline mode as a text editor. It does much the same thing in around half the space (56MB¹).
My digital newspaper, likewise, eats up around 100MB¹ plus a further 50-60MB¹ per issue². Accuweather, just to tell the effing weather (cute icons, but it gets most of the info from the internet) eats up a massive 88.4MB¹. Google maps? 80.3MB with no obvious way to clear cache files, if that is what is taking all the space.

I’m looking down the list of apps and I want to cry. The space consumption of many of these apps is getting into silly figures.
On a device with 16GB onboard³ and no expansion options.

¹ Footnoted every single one, because Apple’s idea of a megabyte does not match my idea of a megabyte. I suspect they are being pedantic and using base 10 (think different!) but it is annoying when you want to drop on an episode of Kyōkai no Kanata and you have to try to work of if this is as big as that…

² I took apart the Android version because Android lets me walk the filesystem. There is a PDF of every page. A high res image, a low res image, text and control data, and a lot of XML files. I don’t understand why with today’s tech they couldn’t just send a PDF file and let the user’s device scale it? Certainly, Adobe Reader copes just fine with the PDFs – in the early days when the app was really buggy, I used to just read the raw page PDFs.

³ On my part: VLC has 3-4GB of videos, there’s 2.5GB of music, 1.3GB of photos, another GB of books between Kindle and iBooks. Which means there is around 7-8GB of “other rubbish”. What?! Actually, it is a little less, as my 16GB device has a 13.4GB capacity – I would imagine iOS itself is stealing a fair whack. But… I guess I should get used to this. The iOS 7.0.4 update is a mere 16.2MB in size, but it will refuse to install itself if you have less than ~780MB free.

⁴ And somewhere along the way, we were talking about losing a little bit of disc space from some redundant configuration files. Kind of puts it into context, doesn’t it? (^_^)

Because when I delete some program I want to delete it choices and all. I do the same with windows.

and under windows various items of dross get left throughout the registry and various windows sub-directories and “program files” and…

I think a proper uninstall, including choices, for RO would be more likely to do the job.

Certainly, Adobe Reader copes just fine with the PDFs

Foxit reader.

Foxit reader.

Which wants to “Modify global system settings” and “Read Email attachments” along with “Full Internet access”?

Sorry. It may be innocuous, but those permissions for a PDF reader are more than I’m willing to accept… Android’s broken shonky app permission system is all-or-nothing. I choose nothing.

Perhaps, thinking of this, the solution is not to fiddle with Choices, but is instead to think of a method whereby an app can present an “uninstall” option that would perform exactly this sort of tidy up?

A !Delete obey file in application folders that gets run when an application is deleted from the filer? Wouldn’t work when deleted from the command line, but might help the current situation? Sort of goes hand in hand with a recycler being integrated into the filer, I suppose.

The reason I suggested a ‘Choices Plugin’ was simply to satisfy that power user craving of reviewing, modifying and/or deleting Choices data manually. There are totally reasonable use-cases, such as when developing software that uses Choices, or testing upgrade procedures.

As a general rule, I think we should be keen on eliminating the common reasons for people to dive inside ‘!Boot’. Isn’t it best left-alone?

I think we should be keen on eliminating the common reasons for people to dive inside ‘!Boot’. Isn’t it best left-alone?

Yup. A setup where the user can, in worst case scenario, delete a user choices directory or run a reset and then be looking at an out of the box user choices situation.
It isn’t idiot proof (nothing is¹) but you do at least eliminate one oops factor. We can but try.

¹ Design a more robust more idiot proof system and a better standard of idiot will evolve to meet the challenge.

There is no better solution that accessing the directory and changing what you want in any way you want. Idiot proofing is a myth. What you are saying is that we should discourage access I think we should encourage it.

Idiot proofing is a myth. What you are saying is that we should discourage access I think we should encourage it.

Myth – yes, that was what I said. Footnote.

Encourage vs. protect.

Make it easy to alter some things make it more difficult to access the critical items – hence my comment about split choices with a method of reset user choices to default.

Now that my principal machine is a Raspberry Pi, which has no hard disk, but an SD card and lots of FAT32FS memory sticks, I am starting to look at my filing systems from a different angle. RISC OS boots using !Boot on SDFS. I keep my private data and software on memory sticks. The SD card seems to be the flakiest – I have just used DiscKnight to repair the SDFS map – so I am anxious to arrange things to make updating RISC OS as painless as possible. Ideally I would like to be able to have the SD card readonly, with a system variable telling the OS which filing system to use for Choices and Scrap. Maybe that is already feasible?

Ideally I would like to be able to have the SD card readonly, with a system variable telling the OS which filing system to use for Choices and Scrap. Maybe that is already feasible?

Have a look at !Boot.Utils.BootRun and you will find
/<boot$dir>.utils.Setchoices
which is a fairly clear basic file, which sets choices.

Modifying it to provide a user modifiable boot choices could be useful.

Maybe that is already feasible?

The only thing on my Pi’s SD card that’s actually used is the stuff in $.!Boot.Loader. Everything else is on the hard drive from my defunct Iyonix which is connected to the Pi using a USB enclosure. If I remember correctly, all it took to get that working was:

configure FileSystem SCSI
configure SCSIFSDrive 4

I use !OpenChoices by Alex Waugh put it in your !boot.resources.configure folder, there is also !OpenPre, !OpenRes & !OpenTasks they work a treat.

We have changed the principle way in which we store data on a RISC OS machine (SD card in a slot rather than spinny rust screwed into a metal/reinforced plastic case). As a result, discs are now extremely interchangeable and in many ways I’ve found myself using a Pi more like my old A3010 than a RPC.

Two things strike me: one is that the hard disc name is often hardcoded into things (Pinboard backdrops being the obvious example, !Builder’s code paths being another). As a result – change the disc name and you’re stuffed. ‘Twas always the case with the HD name on RISC OS, and the answer was therefore ’don’t do it’. Of course – but now we have the added problem that if you duplicate your disc image (ie. make a backup of it onto another SD – an easy way to do a backup, and also a nice way of allowing you to test a new OS image without risk of stiffing your machine,) you run up against the other problem: ‘Ambiguous disc name’. The solution to ambiguous disc name is to ensure they are not ambiguous :-). And as soon as you do that – we trigger the other problems off. Paths referenced in !Boot which reside on the boot drive could be coded relative to !Boot.

The other issue is that !Boot should really be hardware-independent where possible. The !Boot.Loader partition obviously isn’t (I doubt that a boot loader that differentiates between Pi / OMAP 3 / OMAP 4 is possible, but that would be very cool if so); but !Boot itself can and should = if you choose to run the loader from SD card and the !Boot from USB stick then you should be able to remove the USB stick and put it into another OS 5.2 machine and see the same results. The primary problem here appears to be Ethernet – if you copy the files across I’ve found that network access breaks. Having a neutral Boot sequence would allow you to duplicate the disc image, replace with an appropriate Loader, and continue working with minimal downtime on a different piece of hardware.

As a result, discs are now extremely interchangeable

True – though I am not overly keen to stress the SD connector too much. Moreso the clicky-fit one on the Beagle.

Two things strike me: one is that the hard disc name is often hardcoded into things (Pinboard backdrops being the obvious example, !Builder’s code paths being another). As a result – change the disc name and you’re stuffed.

That’s a logical complaint, though in all my years of using RISC OS, I don’t think I have ever changed a disc’s name. I guess I just never thought to do so…

you run up against the other problem: ‘Ambiguous disc name’. The solution to ambiguous disc name is to ensure they are not ambiguous :-). And as soon as you do that – we trigger the other problems off.

Ah – now there is a problem. I’m not really certain what can be done about it. I mean, at some point and in some manner, paths eventually refer back to the specific media.

For example – unless you want something like “<Boot$Dir>.^.Pictures.Backdrops.meh”, you would likely need to refer to the device by name at some stage. You could, I would guess, amend your backdrop paths to use system variables, but don’t expect the OS to do stuff like that for itself.

The other issue is that !Boot should really be hardware-independent where possible.

Isn’t it?

The !Boot.Loader partition obviously isn’t (I doubt that a boot loader that differentiates between Pi / OMAP 3 / OMAP 4 is possible, but that would be very cool if so);

You sort-of can. I don’t think you could make an OMAP3/OMAP4 boot loader as both appear to use the same methodology (MLO and U-BOOT). Those files would need to be changed at source if to work correctly on both types of system equally.

However, as far as I can tell, the Pi and OMAP files have different names so it should be quite possible to build an SD card that would boot on both. I never got around to trying this, but as far as I can work out, it shouldn’t be a problem once you get the OMAP image running (it seems the OMAP is rather fussy about where its boot files are), the Pi on the other hand doesn’t seem to give a fig (part of the amazing beauty of NOOBS, simply “unzip this stuff to here” and it just works).
Obviously, you would need a different RISC OS image for each system. Again, this might be complicated for OMAP3/OMAP4 support, but shouldn’t be a problem between Pi and OMAP.

but !Boot itself can and should = if you choose to run the loader from SD card and the !Boot from USB stick then you should be able to remove the USB stick and put it into another OS 5.2 machine and see the same results.

Pi vs Beagle, perhaps.
Pi vs Panda, perhaps.
Beagle vs Panda, possibly less so.

The primary problem here appears to be Ethernet – if you copy the files across I’ve found that network access breaks.

Ah… Perhaps the different machines use slightly different ethernet drivers and this is coded into the boot somewhere? I can’t help here, I have no network support (one day I’ll get that Ethernet→WiFi dohickey).

Having a neutral Boot sequence would allow you to duplicate the disc image, replace with an appropriate Loader, and continue working with minimal downtime on a different piece of hardware.

…replace the appropriate Loader? Sounds like it might just be easier to run both bits of hardware and sync them from time to time. [I’m a believer in taking the lazy approach if it is easier but ultimately has the same effect ;-) ]