[Oberon] Partitions -> Killer-ap

[cglur at onwe.co.za]

> Since backingUp partitons is currently very tedious, I wondered if
> one could backUp between IDE0/1 by having the same size 
> for corresponding partitions, and copying blocks n to last, where
> n is the first few that have the 'partition linking info' ?
> I.e copy the contents and don't mess with the 'house-keeping'.
> Is this viable (for say 16 to 64 Mb sizes) ?
> 
> PS. as I remember Partitions.Mod also has much undocumented
> facilities ?

Andr wrote:
> Do you mean "disk image"?
> Look for it in http://www.oberon.ethz.ch/betadocu.html
> 
> If I don't err, that's what you looking for.
> It is a viable approach.
> 
OK, that would do. Although rather than the 'backup' (parachute)
view, I prefer to view the project(s) cycling through a sequence of
partitions  -- in this case, just 2.
So one could use the existing commands to: 
   SrcPartn -> TempPartn -> DestPartn
where sizeSrcPartn = sizeDestPartn =< sizeTempPartn
But It is essential that bad blocks are detected.

Important is that it can be done with a few clux (n-o cording) in a Tool
or a script.   Prof Gutknecht mentioned some years back that the 
dir-heirarchy was too liable for 'getting lost in'.  I understood that he
had some magic alternative; but since it has not yet been revealed, I've
found the 3 level 'tree' concept works well for me, with n-o partitions.
I use the 3 level heirachy: partition   /  file  / section
In <Personqal.Tool> I've got (colour coded mnemonically):
Configuration.DoText MountSocEcon
Configuration.DoText MountPop11
Configuration.DoText MountDevlp 
..
Configuration.DoText MountTechn
Configuration.DoText MountLegal
---
Where MountTech is:----
! OFSTools.Mount  Techn  AosFS  IDE1#18 ~
OFSTools.Mount  Techn  AosFS  IDE0#25   ~

System.Directory  Techn:*  

! OFSTools.Unmount  Techn
-------- which immediately goes to level 2: the Dir.:-
........
Techn:DataSlicr.gif
Techn:DigiModem
Techn:DiskStores
Techn:FAX.OCR
.........
----and at level 3, different sub-topics are easily managed in a single
  file with n-o's fast Edit.Search and paste.  The Index is on top. eg. 
Techn:DigiModem  starts like this:-
2. simulating an analog modem on the digital link. 
3. audio synthesis, analysis and coding
4.    Algorithmen der Mustererkennung und ihre Realisierung
5.  articulatory synthesizer of nasal vowels
6. Voice over IP in networked virtualenvironments
...
...
------------ Find.Panel is often used.   And colour coding helps.

I mention this personal arrangement which works well for me, because
I have not found a good 'development enviroment' and hope other(s)
can tell me their successful arrangement.   Here I'm refering to the:
edit, compile, test-run  cycle; which seems inferior to the old Turbo-Pascal
IntgDevEnvr.   Even my small source codes rapidly become unmanagable.

  * what line width do ETH developers use for source code ?
  *  screen layout: User + System track or not ?
  *  fancy aids like 'source code folding'  ?

> Incidentally, try using the google search on the home gae and search for 
> "disk image" or "copy partition".
> 
OK.  

> Which facility exactly is not documented?
> A small hint can help a lot.
Well it's months since I looked at this (and got no replies from this mail
list for several queries !  That everybody now just appears is perhaps the
weather and/or academic cycle ? )  Perhaps I'm mistaken about 
"not documented", I'll investigate, but try this (from yesterday's memory):
  I want to find the 3rd-last *.Obj that I created (I don't want/need to
remember names).   Recently it was revealed that  System.Directory has
flags (which I tested/confirmed) to show the date as the first column
of the dir listing (it still needs to be refined to be ORDERED by date).

To find which flag (without touching the key board), I should be able to:
*.Tool / System.Directory ^ / System.Tool
It fails; as does: System.Directory ^ / Watson.ShowDef  ^

That this can't be fixed is due to 'inconsistent syntax', which I'll
address in another post.

Back to Partitions.Mod (since apparently the mail-list now has 
answerers): I was forced to investigate IDEs: partitioning, MBRs etc;
when I ended up with 6 IDE's all unable to boot PC-DOS.  Substantial
investigation with the standard Microsoft & linux tools showed that
n-o alpha 2001 was much more capable and convenient.

Even 'special tools' downloaded from Seagate and WestnDig. could
not do what n-o did immediately.   Next to ppp, I believe that
IDE problems (losing MBR, partition & booting problem) are the
biggest problems for users (based on Usenet queries).

I think single a 1M4 diskettes with standalone utilitie(s), would
well demonstrate the power of n-o, to potential users.
Single diskette mulinux is usefull for investigating the hardware 
eg. IDE(s), but single diskett n-o for diagnosing IDEs could be a
killer (got to have) application.


-- Chris Glur.