Filer transaction logs

Part of the problem with any RISC OS packaging solution is that RISC OS users are used to the idea that applications can be installed anywhere, and can be arbitrarily copied or moved around. This causes problems because a package manager needs to know where the applications are to update them. The < App$Dir > mechanism is fine for !Applications, but not to other resources like standalone utilities.

So, a slightly off-the-wall idea. The problem is that users move things around. How about a Filer plugin that could do notifications when files are moved or copied? For example, an application might register a regular expression for the filenames it is interested in. When the Filer copies files, it makes a list of the operations that matched the regex, and at the end calls the application (either in memory or on disc) with a record of the changes.

It’s then up to the packaging app to make sense of it. There might be other uses, perhaps a ‘Recently opened files’ menu. Or a backup system.

This wouldn’t capture all the changes (copying from the command line, for example), but it might capture the majority of those made by users. Or maybe too many are already done with other programs that don’t use the Filer (like backup programs)? Is this a bit too much like a Windows-style special case?

I can see a number of holes in this, but thought I’d suggest it anyway…

As we’re throwing ideas anyway. Years ago I planned an application, in Python, that scanned the harddisc and built a database of all system variables of the form App$Dir. It’s main purpose was to get rid of errors due doubleclicking on a file and the Filer not having seen any applications that claimed the filetype.

The idea was that the database would be kept up-to-date by monitoring applications being added/moved/deleted, much like Theo is suggesting. The scanning part has been implemented, as has binding filetypes to a specific application but it never moved beyond that. Maybe it’s time to revisited this.

As Theo mentions in passing, any such mechanism would have to be able to spot duplicate copies of applications. For example, I have a waste basket with deleted items in it (with subdirectories for dates). Every time I upgrade, say, NetSurf, I will move the current copy into the waste basket and install the new one. Also, I have a backup directory which contains a mirror of important stuff.

So you could end up with lots of !NetSurfs and the user needs to be able to say “Ignore that one” or “Use that one”. A simple mechanism might be to allow the user to nominate which location(s) to scan and which to ignore.

Likewise for people with multiple hard drives. For years my RiscPC had a small boot drive (old format) and a main drive in new, long filenames format. I put all of my apps on the second drive and the stuff in Apps on the boot drive was just shortcuts. (My reason was I was softloading RISC OS 4 which had the long filenames support – so the machine couldn’t boot off a new format drive.)

This is exactly the sort of thing RISC OS allows people to do, so it’s stuff that any system such as the ones we are proposing should support. Further more, we shouldn’t insist “our way is the correct way” for where people place their apps (as RiscPkg seems to do).

Further more, we shouldn’t insist “our way is the correct way” for where people place their apps (as RiscPkg seems to do).

OK, here’s a thought – since we need to add a control field to the format specifying hard disc location anyway, how about making it optional? When the user drags an uncompressed package to save it, the manager remembers the location and automatically replaces the suggested location with the old one whenever the same package is downloaded twice.

Sounds like a good idea. And the user can always re-arrange things later, too.

RISC OS users like to be able to structure their file systems in the way that suits themselves. Update systems need to know where particular applications are. To satisfy both needs, some discrimination between public and private space on the filesystem is required. Users must not move stuff in the public sector, if they want updating to work, and update software must not touch the private sector. Am I being too simplistic?

So, a slightly off-the-wall idea. The problem is that users move things around. How about a Filer plugin that could do notifications when files are moved or copied? For example, an application might register a regular expression for the filenames it is interested in. When the Filer copies files, it makes a list of the operations that matched the regex, and at the end calls the application (either in memory or on disc) with a record of the changes.

My suggestion is that we implement file shortcuts/links/aliases properly (which is clearly what Graham intended) then RiscPkg can keep its apps safe and the user can move around (or have multiple) file shortcuts to their heart’s content.