view release on metacpan or  search on metacpan

Storage/html/guide.html  view on Meta::CPAN

exception: $pps_sb of the Root entry (always pps 0) does always refer 
to the big block depot.<p>

It now is easy to read the "files" in: the big or small block list has
to be catched (as did before with root_list and sbd_list) from the big 
or small block depots, the so referred blocks have to be read and at the 
last step the size might have to be truncated to fit to $pps_size.<p>

If the type of a pps is root or storage, at least the variables $pps_ts2d
and $pps_ts2s get initialized. Together these variables build a 64 bit
integer variable, that represents time and date. This variable counts
all 10^-7 seconds, starting at 01/01/1601 00:00.

If the type is root, $pps_sb is pointing to the first big block of the
small block list @sb_list. See just below:<p>


<a name=n34>
<H4>3.4  Where Are The Small Data Blocks?</H4>

The root entry is an exception to the 0x1000 bytes rule of section 3.3. 
The size in the example is 0xf00, so it actually should belong to the small 
block depot. In fact the file of the root entry always refers to the big 
block table. The start block here is 3. When examining this (copy from above):
<p>

<pre>
    00200: fd ff ff ff  05 00 00 00  fe ff ff ff  04 00 00 00
    00210: 06 00 00 00  fe ff ff ff  07 00 00 00  08 00 00 00
    00220: 09 00 00 00  0a 00 00 00  0b 00 00 00  fe ff ff ff
    00230: ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff ff *

</pre>

it results in the chain: {3, 4, 6, 7, 8, 9, a, b}. The so yielded chain 
gives the blocks that provide the space for the small blocks. So small 
block references refer to positions in the "small block file", that in 
this example is build of the big block chain starting with block 3.<p>

<pre>
    small data blocks <=> union of big blocks {sb_list[i]},  

    sb_list  consists out of (number of chain_elements(sb_list))
             elements. The list is read out from the big block depot,
             the lists start is 
             $root_startblock -> property storage 0 -> pps_sb

</pre>

With this in mind, everything needed to pull out some file out of a Laola 
archive is available. You could test this with 
"<a href=lls>lls -s</a>". But there is still more behind the thing.<p>


<a name=n35>
<H4>3.5  Property Sets</H4>

Apart from just storing plain files it is possible, to store special 
structured "database" files. These structured files are called property sets. 
There is a good article about how they are build at Microsoft's web service,
<a href=http://www.microsoft.com/oledev/olesrvr/propset.htm>"OLE Property Sets Exposed" by Charlie Kindel</a>. 
It claims, that accurate information about property sets is provided with 
the Win32 SDK, too.<p>

Summary and further information are
<font color=red>- still to be done ! -</font><p>


<a name=n4>
&nbsp;<p>
<H3>4. Trash Blocks</H3>

Last of the four chapters is "trash data blocks". These trash blocks are
blocks stored in the document without being referred by Laola system. There
should be no such trash, but there is <em>sometimes</em>. Pretty famous
about this is the Microsoft Word Option "fast saving" (switch this off, if
you haven't yet). Thus stored documents are usually consisting by about the
half out of garbage. Another example would be Star Writer 3.1, that by
principle produces 2 big blocks of trash.<p>

Some blocks are just partially consisting out of trash, they could be called 
stinky blocks. This is because of the size of a property does just by 
chance fit exactly to the 0x200 (0x40 at small blocks) bytes border. So the 
rest of the last block of a chain does <em>nearly always</em> contain some 
bytes of rubbish.<p>

Like all trash, data trash is troublesome. In some cases it is simply
annoying because it blows up the files size. In each case it is relevant 
with reference to data security. Because you cannot know what's in there 
you have a lack of control to your own data. In Usenet has been even 
reported that private mail and encrypted password happened to stick in 
a Word file.<p>
 
The good thing is, that unlike nuclear trash, this data trash is removable. 
Just look at demonstration program "lclean" at the source code section of
this document. In case of data trash I've heard, that Microsoft knows
about this OLE bug and provides a fix for 32 bit Windows systems. However,
if you use Windows 3.1 you probably have to rely on lclean.<p>

Comments appreciated!<p> 
<i>Martin</i><p>
<font color="#7f007f"><p align=center>- <i>The End</i> -</font><p>

<a name=n5>
&nbsp;<p>
<H3>TABLES</H3>

<pre>
<a name="t1">

Table 1: Block 0 (laola header)

offset  type value           const?  function
00:     stream $laola_id          !  identifier {d0 cf 11 e0 a1 b1 1a e1}
08:     long 0                    .  ?
0c:     long 0                    .  ?
10:     long 0                    .  ?
14:     long 0                    .  ?
18:     word 3b                   .  ? revision ?
1a:     word 3                    .  ? version  ?
1c:     word -2                   .  ?