Archive info method

Hi Denis,

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.

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.

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.

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 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.

Cheers,
JB
-- 
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
[email protected]

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

iD8DBQBB6MGFrXMSOtiWrO4RAuc8AJ4kva7kPmOf/F4jfacUKZdUxOw+jwCg0rsv
T2uK/KxyWeBlqlAK5Y1gEWM=
=/yDQ
-----END PGP SIGNATURE-----