Unofficial cheatcodes to backup and restore persistent data

[Forester]

utu san,

A most impressive response to my wishlists. Thank you very much.
Several comments and questions come to mind. For extra credit, of course.

A most impressive list of questions. I'm sorry, but I don't need extra course credits: I'm far too old.

It seems to me you have answered a much larger question as well:
how to add 'unofficial cheatcodes' to Knoppix.

Very carefully.

Have you invoked these patches yourself?

Yes. I don't have a comprehensive test suite or an army of test engineers. So no guarantees.

Couldn't these same functions appear as well on the LXDE menu,
perhaps with a few additional strokes?

In my opinion, no. You should not back up an active file system and you certainly can't restore to one. The cheat codes work directory on /KNOPPIX-DATA before the UNIONFS is created.

And, your time zone is what ?

All this is done in MOT (My Own Time). I surmise you are on GST (German Student Time).

The clever Wiki software tells me all times are in GMT from which I infer vBulletin™ have deduced my time zone from my IP address. Scary.

I also noted that the tar/gz and untar/gz operations took a lot
longer than I would have expected, considering how fast
the KNOPPIX compressed file comes up.

Yes I noted that too. Remember compression generally takes a lot longer than decompression. The cheat codes are using /bin/busybox tar, not the real thing. It might be the real thing can make full use of your multi-core CPU and Giga bytes of memory while the BusyBox version can't. I don't know.

You could try BusyBox with lzma compression (that would please kl522) or you could try running the real tar from the /init script. KK has some scary stuff in /init that runs real programs in their own chroot environment. Test your mettle and all that.

This question will allow you to calibrate my expertise:

No, you don't need a special editor to create a patch. The command line will do just fine.

The simple theory is you generate the patch file by comparing the original file with the changed file thus:

diff -Naur script.org script > script.patch

You can later apply the patch to an unaltered copy of script with:

patch < script.patch

I find this works quite well for saving my changes to 'system' configuration files and then reapplying my changes to new configuration files after an OS upgrade or something.

The diff program generates differences with a few lines of context either side and the patch program uses the context, not just the lines numbers, to figure out where the patch should go. Great if someone has changed the file so all the lines numbers have changed. Not so great if they've change the same lines so the context is different. You get a conflict that basically you have to resolve by hand.

That's the basics. It can get a lot more involved than that but since patches are how Open Source software developers get stuff done I guess knowing a little about diff and patch is