AmiSystemRestore - beta testers *no-longer* wanted!

After several months of development, I am happy to reveal AmiSystemRestore for AmigaOS4:



It is similar to Windows' System Restore facility, and allows you to undo nearly any change made to the Sys: partition. Not only is this a first for any Amiga-like OS, but not even Linux has such a facility (*).

What use is it? Well, if you install a new program, or update an existing one, and it installs a buggy or outdated library (etc) over a good working one, then you can use AmiSystemRestore to revert back to the old one which worked. So you can install lots of programs, without worrying whether they have badly written installer scripts

It is intended to be very light weight & "Amiga like", so you can leave it running in the background all the time. It is also intended to be easy to use, yet flexible enough for power users. It will automatically create restore points when something is installed using the official Installer system, as well as when something is updated by AmiUpdate. And it automatically deletes restore points to save space. You can also create & delete restore points yourself.


As it now has all the features I consider "essential", and no more bugs are being found, I need some beta-testers to help test it. Testing only requires you leave it running in the background. AmiSystemRestore heavily patches AmigaOS4, so it is likely that there are still bugs which need fixing - which might stop a program working properly, or in the worst case (but rather unlikely!) stop OS4 from booting. So I am looking for technically experienced users, who know how to backup & aren't afraid of (for example) fiddling with their Startup-Sequence!

If you would like to help test it, then please PM me with your email address.


(* = unless you count the "snapshot" facility of filesystems like ZFS, but they are hardly user-friendly, and certainly not used by any popular Linux distro.)

Nice..

But why would you have it running all day? and why do you need to patch OS4?

RWO

Quote:

To be able to detect file alterations you need to "patch" DOS calls like Open() or Write(). I did some experimentation myself some time ago, the crucial point is not to get the performances down at the same time.

@rwo

Quote:
So I don't forget to run it before installing new software, I would think.

Good work Chris!!!

@abalaban

I thought, there's something like like 'inotify' on linux also for AmigaOS4 which makes it possible to notice changes to the filesystem?

regards,
nexus

@abalaban Quote:
While I have spent a lot of time trying to optimise it, I am leaving a few tricky optimisations until after I am happy there aren't any more bugs to be found.

@emeck Quote:
AmiSystemRestore is designed to be left running in the background all the time... but you don't have to if (for some strange reason) you don't want to.

@nexus

Yes we have filesystem notification but for what ChrisH is trying to do (i.e. backup any changing file, so that you are able to restore it in case of problem) this is too late because the modification already happened when you get the notification.

So the only solution currently is to 'patch' some strategic OS functions using Exec/SetMethod() in order to intercept calls to those functions do what you have to (i.e. save states and make backup) and then leave the control to the original OS function.

That's risky because if your code is buggy you can completly prevent execution of the normal OS function thus making your system's behaviour totally unpredictable.

This is a VERY much needed app! I hope it matures fast and be able to install it and use it. Personally, I wouldn't mind to have it running in the background if it doesn't slow down performance at all.

Needless to say that althought I wouldn't considered myself as AOS4.x power user, I am not afraid if I mess things up and I would gladly participate in any beta tester phase :)

@abalaban

of course, u're right! Thanks for pointing me to the real problem :)

regards,
nexus

Seems a very usefull proggy

I left AmiSystemRestore running while I installed Update 3 for AmigaOS4.1... and it worked perfectly . So in theory, with just a few clicks I could now "roll back" to Update 2 if I wanted!

Update 3's improved MUI seems to have fixed my toolbar buttons looking rubbish, so I have now uploaded a revised screenshot.

Quote:
Why in theory? Does it work or not?

Quote:

This will only catch 68k calls, Exec/SetMethod() is used for native calls.

@all
Just in case it was not clear: Testing only requires that you leave AmiSystemRestore running in the background.

I´d love to test this

I don´t have that much time but keeping it in background while using the miggy i can do

That’s a weary useful application, I have been thinking about something like this myself.

@ChrisH

Wow this looks like a great utility!

Of course I have a couple of suggestions for the current viewing model:

- use some sort of "treeview" style which summarizes by day/week/month (via options)
- you can then open a particular day or week or month to see the changes from that period

In addition, it would be nice if this could be integrated into the installation system somehow. This would enable creating a "named" install (i.e. "Firefox 4.01") and provide for a generic uninstall solution.

This is a follow-up to a thread here:

http://www.os4coding.net/forum/improving-quality-software-releases

Cheers!
Greg

Quote:

heh, just as i create a new topic on a similar subject i find Hans has already beat me.

@gregthecanuck
Quote:
Hmmm, a tree view is probably out of the question, but it might be possible to show a list of months then days, so that you could 'burrow down' to the right date quickly. The main problem is that dates are only stored in human-readable format as specified by the user's Locale preferences, so parsing that back might be difficult...

Quote:
I'm not sure exactlywhat you are asking for, but ASR already 'patches' the official Installer (and AmiUpdate too) to automatically created sensibly named restore points. I guess a bit more info (like a version number) might be useful...

Quote:
Not sure what you mean here. ASR already groups things by date & installer events, not by individual files. If my screenshot looks like it is only covering single libraries, that is because that is how AmiUpdate handles those libraries.