Re: tronconneuse: how is current_position done?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wesley Leggette wrote:
|
| Denis,
|
| If you remember my question about where data offsets (as stored in the
| catalog) are zeroed, I've been looking at the tronconneuse code, and I
| see this code in the constructor:
|
| --------------
|
| tronconneuse::tronconneuse(user_interaction & dialog, U_32 block_size,
| generic_file & encrypted_side) : generic_file(dialog,
| encrypted_side.get_mode())
| {
|
| ...
|
| clear_block_size = block_size;
| current_position = 0;
| initial_shift = encrypted_side.get_position();
| block_num = 0;
| encrypted = & encrypted_side;
|
| ...
|
| }
|
| --------------
|
| Where current_position = 0. get_position is the implemented as return
| current_position. At the same time, initial_shift is set to
| encrypted_side.get_position() and block_num is set to 0. Here, I'm
| assuming that initial_shift ends up being the size of the version
| header.
|

The header_version is not encrypted, as you know. So the first encrypted
bytes witten through an inherited class of tronconneuse must not have an
offset of zero, else they will be fetched in the header_version at
restoration. So the first bytes encrypted are reported to be written at
the current position of the underlying layer (sar). Note that this is
only true for the few first bytes. Encrypted data may use more place
than clear corresponding data (more or less, as defined in each
tronconneuse inherited class). So, the reported offset reported by
troconneuse may differ as the position of the underlying layer (sar for
example).

| So if that assumption is correct, is the position actually zeroed at the
| beginning of the encryption stream?

No this is not true. the encryption stream starts with real encrypted
data, but are layered after the header_version which is not encrypted,
so the offset of the first encrypted byte is the offset of the last byte
~ of the header_version plus one.

| If that is the case, would the
| following be true?
|
| (Here, we are looking at the "virtual file" above the SAR layer.)
|
| Case 1: Encrypted archive
|
|
| +----------+---------------------------------------------------------+
| | version  | Encrypted data                                          |
| | header   |                                                         |
| +----------+---------------------------------------------------------+
|
|            +-----+---------------------------------------+------+----+
|            | EEE | Compressed data                       | TTTT | EE |
|            |     |                                       |      |    |
|            +-----+---------------------------------------+------+----+
|
|            |     +------+--+...................+---------+
|            |     | file |EA|                   | Catalog |
|            |     | data |  |                   |         |
|            |     +------+--+-------------------+---------+
|            ^
|            zero offset

First you diagram is upside down (the lower layer is on top) :-)

No, the zero offset is the first byte of header_version, the compresseur
class gives as offset the one of the underlying layer (sar class), so
compresseur's zero *is* sar's zero (the first byte of version_header).

|
|
| Case 1a: Encrypted archive (If I'm wrong about the first case)
|
| +----------+---------------------------------------------------------+
| | version  | Encrypted data                                          |
| | header   |                                                         |
| +----------+---------------------------------------------------------+
|
| |          +-----+---------------------------------------+------+----+
| |          | EEE | Compressed data                       | TTTT | EE |
| |          |     |                                       |      |    |
| |          +-----+---------------------------------------+------+----+
| |
| |                +------+--+...................+---------+
| |                | file |EA|                   | Catalog |
| |                | data |  |                   |         |
| |                +------+--+...................+---------+
| ^
| zero offset

This is correct.

|
|
| Case 2: Compressed archive
|
| +----------+---------------------------------------------------------+
| | version  | Compressed data                                  | TTTT |
| | header   |                                                  |      |
| +----------+---------------------------------------------------------+
|
| |          +------+--+..............................+---------+
| |          | file |EA|                              | Catalog |
| |          | data |  |                              |         |
| |          +------+--+..............................+---------+
| ^
| zero offset

This is also correct.

|
|
| If case 1a is true, how is the position determined? I.e. how is it
| possible to calculate the underlying position when current_position = 0?

when the tronconneuse object is constructed, the underlyling layer is in
the state where the header_version has been read. So the offset points
to the first encrypted byte. This value is used when initializing the
tronconneuse object.

|
| Also, where is initial_shift used?

at restoration time to get the place of the data to restore through the
tronconneuse inherited object.

|
|
| Thanks,
| Wesley
|
|
|
|

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFCQzFQpC5CI8gYGlIRAjcHAJi9sNLIyLavfDvKaWZleIoufCnxAKDG0mNN
kT0azpLBQBoRm7jgjbUdHQ==
=Ecf0
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click