Re: KDAR, and libdar suggestions/questions

Johnathan Burchill wrote:
> Hello Denis,

Hello Johnathan,

> 
> First, I have a basic implementation of dar for KDE using libdar. I call it 
> "kdar" (go figure).

good, it seems the way KDE labels its applications.

> 
> All it does now is list the contents of an archive in a collapsable 
> directory tree view, and it can isolate an archive.

thus the most difficult is already done ! :-)

> 
> Figuring out how to get the callback functions to work with the qt was 
> quite a hassle, but that is more a reflection of my ignorance about 
> callback functions and passing function pointers as arguments to other 
> functions, not any inherent difficulties in the implementation. Once you 
> know how, it's easy, right?! :) 

yes, it should be :-)

> 
> I'd like to get your opinion on the API for the tar_listing callback. I 
> suggest that the two ui_printf statements in "catalogue::tar_listing" be 
> removed since the GUI frontend developer should have a say in how the 
> tar_listing output is explained to the user. For example, in my 
> collapsable directory tree view, the column headings explain what each 
> column is, so I don't need the extra ui_printf statements spitting out 
> column headers to the warning_callback function.

that's absoluteley right. I move theses ui_printf lines from libdar part 
to dar command-line code (catalogue.cpp to dar.cpp). see CVS. Thanks for 
feedback.

> 
> My main API question though, is this: is there an easy way to get an 
> on-demand listing of a given directory? I don't need a recursive listing 
> of the contents of the directory, which is what "libdar::op_listing" 
> currently does. I'm thinking of the equivalent to "/bin/ls -a ." as 
> opposed to "/bin/ls -aR .". I thought it could be done by passing the 
> appropriate filter mask to "op_listing", but I've had no success.

OK, actually only the -X/-I equivalent options are implemented for 
listing. Hopefully dar manual page is up to date with that "feature".

> 
> When I try with the command-line version of dar, e.g.
> 
> "dar -l test_archive path/to/the/requested/directory"
> 
> I get a complete listing of the archive, when all I want is the listing for 
> the files in the given directory. The man page for dar suggests that 
> adding the [list of paths] at the end of the command line should make the 
> "-l" command act on the listed paths only, as long as there are no 
> conflicts with the -X and -P options. Is this the intended behaviour for 
> the -l command?

maybe that's not exactly the -P/[list of path] you need ? Calling 
several time op_listing each time changing the mask, makes a big 
overhead, because each time libdar considers it is facing a different 
archive, thus each time extracts the catalogue, and potentially asks for 
slices.

This let me see that an "open/close" set of calls would be more 
appropriate for libdar API (OK, let's say it will be for API version 2):
	some_data_structure open(archive basename and path)
	S_I op_listing(some_data_structure, ...);
	S_I op_restore(some_data_structure, ...);
	S_I any_other_calls(some_data_structure,...);
	S_I close(some_data_structue);

this would open the door to a thread safe libdar library (which is not 
the case actually), and would only require once, that the user  provides 
slices, while it would allow several operations 
(listing/restorations/isolations/etc.) on a given archive.

OK, back to API version 1, now.

> 
> Do I have to dig deeper into the libdar API to be able to extract the 
> contents of a given directory directly from the catalog, or is there a 
> straightforward patch to libdar::op_listing?

I don't see a way to actually get a single given directory listing from 
the API, nor I see a straighforward patch to libdar::op_listing. The 
overhead generated to computer and user (asking slices), do not let me 
think this would be a good idea to repeatedly call op_listing on a given 
archive.

> 
> The reason I'd like "on-demand" directory listings is that waiting for a 
> listing of a 15-CD archive was very slow (after 45 minutes I gave up), and 
> took up 95% CPU and 60-80% RAM. With on-demand listings, I could list the 
> top-level directory in my tree view, then populate the subdirectories as 
> the user clicks on them.

OK, now I understand your need.

How much time it takes to dar command-line to list the same archive to 
/dev/null (I mean : dar -l archive > /dev/null) ? Why this question ? to 
know if it is dar's side or GUI's side slowness. Have you tried the 
--enable-mode=64 option with the configure script (rawly, it speeds 
execution by 4 times and cut by two the memory requirements) ? More 
generally, which option have you given to the configure script ?
> 
> I appreciate your feedback,
>

I appreciate yours too ! :-)

> JB
> 

Denis.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf