!SysMerge doesn't Unlock files

This is a very minor observation about !SysMerge in PlingSystem.

Install_Update doesn’t appear to Unlock files before trying to replacing them, there’s a similar issue with the Rename’s of the !Sprite files.

I’m not sure how I had locked files, but have a vague recollection that Acorn’s original !Boot might have them locked by default.

Should any tool really automatically unlock files? Maybe the user locked them for good reasons? E.g. to stop tools to fiddle with random files?

!SysMerge is of course a bit of a special case, doing changes to an area which contains OS parts that may not be considered “user-serviceable”, but since RISC OS provides open access to all the intrinsics of the OS, I would propose to keep the RISC OS default “the user knows best” principle. Although for specific distributions e.g. aimed at beginners, a different approach would be much more user friendly.

If any file cannot be replaced or renamed, does the user know?

What we can’t have, surely, is something that fails silently – the user doesn’t know it has failed.

If any file cannot be replaced or renamed, does the user know?

As I recall SysMerge does log the result of each replacement, if you know to look in the log file it creates and know where it creates it.

Check, seems to be logging at !Boot.log and <system.log<\code> on this RPCEMu setup

Letting people know where to look might be handy.

Letting people know where to look might be handy.

Letting people know there’s something crucial to look for might be handy.

the user doesn’t know it has failed.

Am I the only one tugging my hair in a mixture of disbelief and frustration?

We have a UI. Use it!

The file ‘mehblah’ needs to be updated but it is currently protected against being changed.
[Update the file anyway] [[Leave the file alone]]

However… see the second question on page 7. It’s talking about file versions rather than writability, but I imagine that the same pitfalls could still apply (although probably to a lesser extent since RISC OS has fewer ‘grouped’ files).

My personal opinion is that a merge should be as ‘atomic’ as possible. Maybe check the access to the files before installing anything, and pop up a “can’t do this update because files are locked” error. Only if all files are unlocked would it then install everything.

I haven’t looked at the code to see how practical this is though :)