Re: Re: tronconneuse: how is current_position done?

On Thu, 2005-03-24 at 22:29 +0100, Denis Corbin wrote:
> -----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.

So when using the tronconneuse, say if you want to store an offset into
the catalog, do you store the value returned by get_position(), or do
you have to add initial_shift to the position?

(Sorry, I just can't get it through my head ;) I can grasp HOW the
offset position stored in the catalog is calculated. I just can't figure
out WHERE in the code this calculation occurs. And is this offset
position always the same number used when calculating block_num?

Thanks,
Wesley

> 
> |
> | 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
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions
-- 
Wesley Leggette <lists-+42/j/[email protected]>

GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCQ0FzKiBWiPhIm90RAqBZAJ4pSAxTIRzKc5+yMjVdh4yVotINEwCfWUjy
CACPiH8RnGN+jXcIso8zJxE=
=hvtz
-----END PGP SIGNATURE-----