[Oberon] Re. cloning a filesystem or an OS.

[Chris Glur]

PETER EASTHOPE wrote-
> This should apply equally to NO and Aos and 
> at least partially to other systems.
> 
> Back in February of 2002 Bernhard Treutwein 
> mentioned cloning a system; the primary focus 
> was on FAT filesystems.
> 
> At the part level, provided both parts are 
> the same size and there is enough space for 
> an image file elsewhere, this works and is 
> documented.
> Partitions.PartitionToFile IDEs#m ImageFile ~
> Partitions.FileToPartition IDEt#n  ImageFile ~
> 
> If the source is smaller than the target, I'm not 
> sure the residual space on the target will be 
> useable. 

Yes useable, since the destination-partition would
then just contain 1 file, albeit a big-file derived from
a whole partitition.   Since IDE's are so big lately,
I've got a 'Configuration.DoText BakAll2Sgt80' script
which copies all my 16 [except SYS:] partns to a 
BIG bakup-partn. as 16 files.

> If the source is larger than the 
> target, the second command ends with a trap and 
> the target filesystem is likely broken.

Well I guess that's like writing to a partn, which overflows;
which has happened to me.  But AFAIK only the last failed
store was lost. And I then use the corresponding *.Bak.

> Copying all files from one Aos filesystem to 
> another is easy using these commands.
> System.Directory  Source:* ~
> FileSystem.GenCopyFiles  Source:  Target: 
>    ...
> ~

And here too, if the target filled up before the 
sequnce of 'System.CopyFiles' completed, I guess that
only the last one would be 'lost'.

> But if the objective is to clone an OS, copying 
> files won't copy the bootloader and the inverse 
> of !Partitions.UpdateBootFile is not obvious.  

As I see it, the bootloader is not part of the Oberon clone.
It's part of the 'computer' -- applicable to all the installed OSs?
I've never graduated to using a [non-fd0, smart bootloader],
[like I've never 'stabilised' to use linux as root: the continual
changes needed means that I can't settle into using 
non-root permission] smart bootloader
A single computer/disk-system can contain several OSs
and clones of OSs. Only ONE of which is selected at boot
time.

My one box can boot [via grub] to 'a' linux and Wxx.
All the other linux-es need fd0 booting.
The theory of having [only] the latest is marketing garbage.
Real life is that when you install the latest version [eg.
of linux]  you won't be able to do some thing that you
occasionally did in version n-2, which task you will only
need after 6 months.  The reality is that you must 'drive
without a bonnet & be prepared to slot-in other parts at
any time'.

I'll have a look at !Partitions.UpdateBootFile tomorrow;
especially since I've now got a 'colour-each-block/construct
-differently-to-help-analyse-code'  and Partitions.Mod
has got nice/clean code from what I've previously
read/modified-extended.

I'm guessing that a 'bootloader' is placed in the MBR.
This is rather drastic !

> So can anyone help with these questions.
> * In the partition method, can the problems of 
> differing source and target sizes be solved?
> Ie., can the filesystem be extended in the first 
> discrepancy and terminated properly in the second?
> 
sourceSize < targetSize ==> spare space available for other file[s]
targetSize < sourceSize ==> expect a trap. Obviously it can't DO
targetSize = sourceSize: perhaps achievable when both have the 
same number of [512 byte sized - I think] blocks.

> * In the filesystem method, can the BootFile be 
> extracted from an executable part?  I'll guess 
> that with the correct block numbers  
> Partitions.PartitionToFile dev#part file [block blocks] ~
> and some editing might work.

> If there are any constructive answers, please 
> consider adding them to your Web based documentation.

I've got a lot of documentation & some experience with
x86-bootloaders.  Let's first see some other contributors.

Long ago I got no reply to my query about the 'disassembler tool'
which had some bugs but was remarkable. Now "sem" finds 
nothing relevant in *.Tool
We need to work at asm-level to analyse the MBR.
There are other disassemblers available, but it's nice to be 
able to stay in ETH-oberon, to just paste the work-log for
later emailing.

== Chris Glur.