[Dar-libdar_api] Re: Archive info method

[Denis C. <dar...@fr...>]

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

Johnathan Burchill wrote:
| Hi Denis,

Hello Johnathan,

|
| I've been thinking for awhile about a way to get info about a dar
archive.
| The 3.0 API returns info via the op_listing method, i.e. archive size, #
| slices, version no., whether it's encrypted, # directories, # regular
| files, etc.
|
| For example, a listing of an archive from the command line gives:
|
| Extracting contents of the archive...
| Archive version format               : 04
| Compression algorithm used           : bzip2
| Scrambling or strong encryption used : yes
| Catalogue size in archive            : 54380 bytes
| Archive is composed of 1 file(s)
| File size: 38243193 bytes
|
| CATALOGUE CONTENTS :
|
| total number of inode : 4211
| saved inode           : 4211
| distribution of inodes
|  - directories        : 235
|  - plain files        : 3976
|  - symbolic links     : 0
|  - named pipes        : 0
|  - unix sockets       : 0
|  - character devices  : 0
|  - block devices      : 0
| hard links informations
|    number of file inode with hard links : 0
|    total number of hard links           : 0
| destroyed entries informations
|    0 file(s) have been record as destroyed since backup of reference
|
| Then the user is asked whether to continue listing the archive.
|
| In KDar, we don't use the op_listing method, since the full listing is
| never needed. We use the get_children_of method to build up the archive
| tree listing on an "on-demand" basis.

Yes, of course.

|
| It would be nice to have a method for returning the archive info without
| using the op_listing technique. Do you have a plan for this? Perhaps all
| it would take is making the "get_header()" call a public member of the
| archive class, instead of being private? Then each developer can parse
the
| info using their own user_interaction class. Basically, I think the
| details of how the archive info is presented to the user should be
| abstracted away from the library and into the client applications,
through
| the user_interaction class.

This should not be a problem. I add it in the "TODO" list.

|
| Also, it would be useful to have a way to determine if an archive is
| encrypted besides trial-and-error. Currently, in KDar you have to
remember
| whether an archive is encrypted, and if it is but you don't specify the
| right encryption algorithm, the archive fails to open with an error.
| The only way that I can see to make this transparent to the user is for
| KDar to catch the error, and try opening the archive again, but with a
| different encryption algorithm.

Well, in the archives there is only a flag telling whether the archive
has been encrypted or not. There is no information about the algorithm
used (nor there is about the password :-) sorry just kidding). This is
intentional. The flag is just used to be able to inform the user that in
case of wrong encryption or password, dar may return that the archive
has an incoherent structure. This warning does not shows for clear archives.

|
| From this point of view, perhaps the crypto algorithm argument to the
| "open" archive constructor is redundant. Couldn't the library query the
| archive header, see what type of encryption algorithm is used, and
request
| a password through the user_interaction only if encryption is used?

I initially thought that the user should have to record both chosen
encryption algorithm and chosen password to decrypt a given archive.
This is the reason why the cipher used is not stored in the archives.
This makes just a bit more difficult to crack an archive. But you are
right (assuming you would argue this way) this reason is very weak, and
for the user, not having to remeber the encryption used is just more
confortable, while it does not bring any secury problem. So it will be
changed for user confort. :-)

|
| I realize this possibly involves changes to the api, so I don't expect
| modifications for the upcoming release. These are some suggestions for
| future enhancements.

Of course.

|
| Cheers,
| JB

Cheers,
Denis.

P.S.: have you seen kdar on slashdot ? :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFB7XZspC5CI8gYGlIRAuthAJ4kPVeL5JPvepf2UTjvMcoMae7pMgCgnYuQ
/O1/Hn/lpHuz2YDBF3lcHlY=
=MPUT
-----END PGP SIGNATURE-----