[Oberon] Re (2): OFS directory-format documented ?

[Chris Glur]

Bernhard wrote:
> got my mail to your gmail account returned...

Yes, with N-O needing\able-to enter all manually 
there's mistakes. That's why I'm enthusiastic about 
EditKeys.Tool for macros.

> not very long ago I bought two twin CF-Card to
> IDE adapters each for about 10 EUR including
> shipping & handling from Honkong to Germany
> via Ebay. Although they say that they ship to
> the European Community, but I guess that they
> may ship also to South-Africa, so you could
> try it. This is a 5-Pack of Dual CF-IDE
> Adapters:
> 
> "http://cgi.ebay.de/5X-Doppelseitig-CF-C....

]CF Karte wird bei jeder Seite(Frontseite und Rückseite) als 
] Master oder Slave erkannt. 
 So depending on which 'side' you insert the CF, it's 
recognised as slave or master ?
 
 ]Stromversorgung über Notebook-IDE-Kabel 
 
 Yes, one with a notebook-IDE-adaptor would be great.
 But they don't list these ? Or would one use an extra
 notebook-IDE-adaptor to standard-IDE-adaptor first ?
 That's problematic because you want only small adaptors
 inside the notebook.

Perhaps this would be cabled so that the bigger
standard-IDE-adaptor side would be outside of the
notebook ?     In my case I'd bring the cable out
 via an existing hole. How long is the cable ?
 How small a diameter hole can it pass through ?
 
For my standard boxes which are all open with the 
IDE-cables lying free to interplug IDEs, CFs sound good ?
================

> > In fact for a big-directory all the 'arg-words' are
> > multiples of 29; and the 1st chronologically entered
> > File's arg-word: 5829; equals 201*29.

Ben wrote:
> I can't answer your more general question about documentation of the
> on-disk format of OFS, but the book Project Obeorn provides some
> insight into the magic number 29:
> 
> Quote:
>     3. Sector pointers are represented by sector numbers of type
> LONGINT. Actually, we use the numbers multiplied by 29. This implies
> that any single-bit error leads to a number which is not a multiple of
> 29, and hence can easily be detected. Thereby the crucial sector
> addresses are software parity checked and are safe (against single-bit
> errors) even on computers without hardware parity check. The check is
> performed by procedures Kernel.GetSector and Kernel.PutSector.
> 
> Source:
>     Project Oberon "Edition 2005", Page 174
>     http://www.oberon.ethz.ch/WirthPubl/ProjectOberon.pdf

Yes *.pdf is a curse. Many viewers can only step-pages, 
so getting to pg 174 is a problem. I usually [when possible]
convert pfd -> txt -> ETH-Oberon format; where I can colour
the text as I analyse it.

Under linux: gv can go directly to pg 174 [of 441 tolal !],
and there's a utility which can 'translate page n...page n+1
to text'.  But it all adds to the confusion, compared with using
N-O when you just need to look [& imagine it opening] at
the fileID.

Also it seems that Wirth's description doesn't much 
correspond to the later ETH-oberon file system,
which seems mostly to be the creation of Pieter Muller.
Perhaps HIS desertation contains some info ?
I'll google.

Empirically my hard labour has discovered: --
Partitions.ShowBlocks  <device#partn>  1031  33
 will show a directory-format starting at Block 1032.
But not strictly alpha-sorted, as they are when initially Storing to a
clean partition ?

Bytes 32..35 [%20..23] of the 40 byte directory entry gets you to the 
block adr. of the bytes 0..31  fileName.        
And by using  
Desktops.OpenDoc  Calculator.Panel
 to [Bytes 32..35] * 8/29 + 1024
 you see the actual file plus its 'header'.

So:  IDE0#42 1032
00000000 8D A3 1E 9B 03 00 00 00 57 00 00 00 00 00 00 00 ........W.......
00000010 44 65 6C 61 79 4E 73 6E 61 6B 65 2E 42 61 6B 00 DelayNsnake.Bak.
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 9F AB 00 00 
  means file: DelayNsnake.Bak can be found from the 'arg': '9F AB'
 which is in Intel/reverse order. Hence %AB9F = 43935
and 43935  * 8/29 + 1024= 12120 + 1024 = 13144

And: Partitions.ShowBlocks  IDE0#42  13144 33   shows:
IDE0#42 13144
00000000 86 1D A7 9B 44 65 6C 61 79 4E 73 6E 61 6B 65 2E ....DelayNsnake.
00000010 42 61 6B 00 00 00 00 00 00 00 00 00 00 00 00 00 Bak.............
00000020 00 00 00 00 04 00 00 00 11 07 00 00 46 D4 00 00 ............F...
00000030 A2 67 01 00 9F AB 00 00 BC AB 00 00 D9 AB 00 00 .g..............
00000040 F6 AB ....... = which is a 1Kb header
And:IDE0#42 13145
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 F0 01 B9 05 00 00 01 4F ...............O
00000040 62 65 72 6F 6E 31 30 2E 53 63 6E 2E 46 6E 74 00 beron10.Scn.Fnt.
00000050 03 00  ....... = shows %38 bytes followed by the actual file.
 
Using eg. ET.* to cut off these first %38 bytes, recovers the file
with it's font & colour info, provided the file [inevitable
for small or newly entered files] is in consecutive blocks.
! But discovered this shows the wrong size for System.Directory x*\d 
which could corrupt the system !
=============

I'm putting this to Edgar's wiki in the hope that a fuller description
of the current ETH-Oberon file/directory format be eventually 
exposed.

Q- is AOS/BB's file system different from N-O's ?

Thanks for any feedback,

== Chris Glur.