[Dar-libdar_api] Archive info method

[Johnathan B. <jk...@sh...>]

Hi Denis,

I've been thinking for awhile about a way to get info about a dar archive.=
=20
The 3.0 API returns info via the op_listing method, i.e. archive size, #=20
slices, version no., whether it's encrypted, # directories, # regular=20
files, etc.

=46or 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)
=46ile 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=20
never needed. We use the get_children_of method to build up the archive=20
tree listing on an "on-demand" basis.

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

Also, it would be useful to have a way to determine if an archive is=20
encrypted besides trial-and-error. Currently, in KDar you have to remember=
=20
whether an archive is encrypted, and if it is but you don't specify the=20
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=20
KDar to catch the error, and try opening the archive again, but with a=20
different encryption algorithm.

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

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

Cheers,
JB
=2D-=20
Johnathan K. Burchill, Ph.D.
Department of Physics and Astronomy
University of Calgary
2500 University Drive N.W.
Calgary, AB T2N 1N4
Canada

(403) 217-4286
jk...@sh...