[Dar-libdar_api] Re: Archive info method
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
|
From: Denis C. <dar...@fr...> - 2005-01-18 20:50:03
|
-----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----- |