Re: Re: Archive info method

On Tuesday 18 January 2005 13:49, Denis Corbin wrote:
> 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.
>

Thanks.

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

Thanks! In fact, I agree that witholding the encryption type does not 
improve the security substantially.

On the other hand, as DAR's author, it's your call. KDar could create a 
hash of each archive, and keep a database of archives and encryption 
types. Or, we could use EA to hold that information. Of course, having it 
in the archive header is easiest for KDar and other clients, so that's 
where my vote goes. :)

>
> | 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 ? :-)
>

Yeah, I saw KDar on slashdot. I'm quite pleased with the tutorial by Joe 
Barr. Unfortunately he didn't describe the backup process. Also too bad he 
reviewed the version with the individual file-restore bug, but I take 
responsibility for that, and for some of the flak that it created. What 
can I say? It was a regression, and I was enjoying a nice holiday in 
Italy! :)

Most interesting was the general nature of the comments: "Making backups is 
easy! I just do X, Y, Z (usually including tar...)." It is a "News for 
nerds" forum, after all; but I suspect that there are plenty of people out 
there who don't make backups for lack of an "easy" way to do it. It's good 
to see that the article generated a lot of discussion about backups, 
though!

There was also a tutorial on backups, which featured KDar, in the November 
issue of Linux Format (a UK-based magazine). It was quite positive, too.

Cheers,
JB

>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Dar-libdar_api mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

-- 
Johnathan K. Burchill, Ph.D.
[email protected]

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

iD8DBQBB7aS0rXMSOtiWrO4RAtENAJ9TnpqRzrKVpzl3IAUjO8LIr1lkaACfQQ8k
zLhcupWeb1CNfKJcbTXKs8k=
=Wj28
-----END PGP SIGNATURE-----