dar-libdar_api — discussion area for developpers that want to use the libdar API

[Dar-libdar_api] entree_stats access

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

Hi Denis,

It's been a long time, but I've finally put some spare time into 
adapting KDar to KDE4 and libdar-4.0.

I'd like to be able to get information about existing archives, 
basically the info that is stored in the catalogue and which is 
accessible by 

entree_stats   catalogue::get_stats () const.

Since you don't want the user to call the 

const catalogue &   archive::get_catalogue () const 

function directly, could we have a passthrough for the entree_stats?
This patch for cvs HEAD is what I have in mind.

Index: archive.hpp
===================================================================
RCS file: /cvsroot/dar/dar/src/libdar/archive.hpp,v
retrieving revision 1.35
diff -u -r1.35 archive.hpp
--- archive.hpp 14 Jan 2007 21:16:07 -0000      1.35
+++ archive.hpp 4 Apr 2007 13:24:46 -0000
@@ -494,6 +494,9 @@
            /// not part of the API but must remain a public method 
for been usable by the database class
        const catalogue & get_catalogue() const { if(cat == NULL) 
throw SRC_BUG; return *cat; };

+            /// gives access to archive statistics. Obtained from the 
archive's catalogue.
+       const entree_stats get_stats() const { if(cat == NULL) throw  
SRC_BUG; return cat->get_stats(); };
+
     private:
        enum operation { oper_create, oper_isolate, oper_merge };



Cheers,
JB

Re: [Dar-libdar_api] Problems with the Python bindings

[Denis C. <dar...@fr...>]

Martin Bergner wrote:
> Hi,

Hello Martin,

I cannot bring you much help about the Python bidings (I don't speak
(yet?) Python :-) ). I guess, Wesley Leggette could help as he is the
author of this bindings, however he does not seem to be subscribed to
this mailing-list. At the bottom of the page [1] you can find a link to
contact Wesley.

Sorry not being able to help you much more. If however I misunderstood
the problem or if you think the problem is linked to libdar itself (not
to the Python bindings), please let me know.

Kind Regards,
Denis.

> 
> I'm one of the developers of HUBackup [0] in Ubuntu. As the program is
> written in Python, we now decided that it would be nice if we used the
> DAR Python bindings [1]. 
> 
> However, there seem to be some problems with the bindings themselves. I
> could fix some, but I'm now at a point where I don't really know where
> the problem is exactly. 
> 
> The problems I fixed were:
> 1. The bindings wouldn't compile in one step. Once invoking "make"
> failed, doing it a second time worked. The fix was a small %import
> statement in user_interaction.i
> 
> 2. The bindings wouldn't work with the default Debian mode of 64. I
> fixed that by changing the Makefiles and adjusting one or two *.i files.
> The bindings now compile and load with every mode.
> 
> 3. The bindings didn't work when specifying a user_interaction object.
> As python does not work with something like that:
> 
> test.py:
> *********************************
> #!/usr/bin/env python
> def fun_test(param1):
>     print param1
> 
> def fun_fail(param1):
>     if param1 == None:
>         fun_test = None
>     else:
>         fun_test(param1)
> 
> fun_fail("Bla")
> 
> *********************************
> But that was also easily fixable.
> I will attach a small patch that fixes these problems when the patch is
> applied. I deleted the Perl and Ruby bindings stuff since it is not
> really necessary.
> 
> Our code now successfully uses the List job and I can even see all the
> files in an dar archive so that works correctly. However, I can not use
> the Extract Job. When I set Verbose to "true" I get the message
> "Extracting contents from the archive" but that is it. The dar archive
> is small enough so that it shouldn't take long to extract something.
> However, the "Extracting ..." is the last message that I get. (My
> interaction stuff is ok since it works with the list job).
> 
> I suspect that there is a problem with the masks. I get a lot of
> "swig/python detected a memory leak of type 'std::string *', no
> destructor found." warnings which I think appear in mask. Also, I can't
> use the list job with a specific mask to only show parts of the files in
> the archive.
> 
> I currently use the following code snippet to access the extract object:
> 
> Excerpt from hurestore.py:
> *********************************
> from dar import job
> class hurestore:
>     restore(self):
>         job_extract = job.Extract()
>         job_extract.interaction = gtk_interaction(self.window)
>         job_extract.root_path = self.path_to_which_restoring
>         job_extract.archive_path = self.path_where_archive_is
>         job_extract.archive_name = self.archive_name
>         job_extract.verbose = True
>         job_extract.selection = True
>         job_extract.run()
> *********************************
> 
> This gives me the above behaviour.
> 
> This is all the information I think are interesting so far but if you
> need more, just ask.
> 
> Thanks in advance, 
> Martin
> 
> [0] https://launchpad.net/hubackup
> [1] http://darbinding.sourceforge.net
> 
> 

[Dar-libdar_api] Problems with the Python bindings

[Martin B. <mar...@on...>]

Hi,

I'm one of the developers of HUBackup [0] in Ubuntu. As the program is
written in Python, we now decided that it would be nice if we used the
DAR Python bindings [1]. 

However, there seem to be some problems with the bindings themselves. I
could fix some, but I'm now at a point where I don't really know where
the problem is exactly. 

The problems I fixed were:
1. The bindings wouldn't compile in one step. Once invoking "make"
failed, doing it a second time worked. The fix was a small %import
statement in user_interaction.i

2. The bindings wouldn't work with the default Debian mode of 64. I
fixed that by changing the Makefiles and adjusting one or two *.i files.
The bindings now compile and load with every mode.

3. The bindings didn't work when specifying a user_interaction object.
As python does not work with something like that:

test.py:
*********************************
#!/usr/bin/env python
def fun_test(param1):
    print param1

def fun_fail(param1):
    if param1 == None:
        fun_test = None
    else:
        fun_test(param1)

fun_fail("Bla")

*********************************
But that was also easily fixable.
I will attach a small patch that fixes these problems when the patch is
applied. I deleted the Perl and Ruby bindings stuff since it is not
really necessary.

Our code now successfully uses the List job and I can even see all the
files in an dar archive so that works correctly. However, I can not use
the Extract Job. When I set Verbose to "true" I get the message
"Extracting contents from the archive" but that is it. The dar archive
is small enough so that it shouldn't take long to extract something.
However, the "Extracting ..." is the last message that I get. (My
interaction stuff is ok since it works with the list job).

I suspect that there is a problem with the masks. I get a lot of
"swig/python detected a memory leak of type 'std::string *', no
destructor found." warnings which I think appear in mask. Also, I can't
use the list job with a specific mask to only show parts of the files in
the archive.

I currently use the following code snippet to access the extract object:

Excerpt from hurestore.py:
*********************************
from dar import job
class hurestore:
    restore(self):
        job_extract = job.Extract()
        job_extract.interaction = gtk_interaction(self.window)
        job_extract.root_path = self.path_to_which_restoring
        job_extract.archive_path = self.path_where_archive_is
        job_extract.archive_name = self.archive_name
        job_extract.verbose = True
        job_extract.selection = True
        job_extract.run()
*********************************

This gives me the above behaviour.

This is all the information I think are interesting so far but if you
need more, just ask.

Thanks in advance, 
Martin

[0] https://launchpad.net/hubackup
[1] http://darbinding.sourceforge.net

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Denis C. <dar...@fr...>]

Hello Glen,

How about the kdar update? If you meet any problem don't hesitate to
report them here.

Regards,
Denis.

Denis Corbin wrote:
> Glen Ogilvie wrote:
> 
>> Hi Denis,
> 
> 
> Hello Glen,
> 
>>
>> Thank you for the details, I had discovered some of them a little
>> last night, but it was hard to figure out.
>>
>> I'll be having a go at updating some of kdar bits over the next
>> weekend.  I appreciate all the help and time you've giving me, really
>>  encourages me to work on making kdar work well.
>>
> 
> If you see any additional differences between the two APIs, feel to
> report them here, this will consolidate the Points I have found. With
> all this information I will be able to create a document to be inserted
> in dar's documentation.
> 
> 
>> Regards Glen Ogilvie
> 
> 
> Regards,
> Denis.
> 
> 
>> [...]
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Denis C. <dar...@fr...>]

Glen Ogilvie wrote:
> Hi Denis,

Hello Glen,

> 
> Thank you for the details, I had discovered some of them a little
> last night, but it was hard to figure out.
> 
> I'll be having a go at updating some of kdar bits over the next 
> weekend.  I appreciate all the help and time you've giving me, really
>  encourages me to work on making kdar work well.
> 

If you see any additional differences between the two APIs, feel to
report them here, this will consolidate the Points I have found. With
all this information I will be able to create a document to be inserted
in dar's documentation.


> Regards Glen Ogilvie

Regards,
Denis.


> [...]

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Glen O. <ne...@li...>]

Hi Denis,

Thank you for the details, I had discovered some of them a little last
night, but it was hard to figure out.

I'll be having a go at updating some of kdar bits over the next
weekend.  I appreciate all the help and time you've giving me, really
encourages me to work on making kdar work well.

Regards
Glen Ogilvie

On 2/22/07, Denis Corbin <dar...@fr...> wrote:
>
>
> Glen Ogilvie wrote:
> >
> > Dennis, have you managed to put togeather a summary of the API
> > changes?  It would help in updating kdar to use them.
> >
>
> Point 1: [taken from the ChangeLog and diff] :
>     added -[ and -] options (file selection from file listing)
>     Important consequence for libdar user programs:
>     the fs_root argument is now expanded to full absolute path inside
>     libdar, thus the mask you will give for path inclusion/exclusion
>     (the "subtree" argument) will be used against full absolute path
>     of files under consideration for the operation. Assuming you have
>     fs_root=tmp/A and the current directory is /var/tmp, your mask will
>     be used against strings like /var/tmp/A/some/file. (instead of
>     tmp/A/some/file as in the previous API version). Things are equal
>     if the fs_root is given an absolute path.
>
> In other word, the fs_root argument (in all public archive's methods
> that use it) has to use become an absolute path, when user provides a
> relative path.
>
> fs_root is an object of class path, the is_relative() method can let you
>   know whether a path is relative or not. If it is relative, find the
> current working directory (getcwd() system call for example) build a
> temporary path object (let's call it cwd_path) with the getcwd() string
> (constructor works with std::string that can be also built from char *)
> and before passing fs_root, set it to absolute with the path::operator+
>
>      fs_root = cwd_path + fs_root;
>
> This has to be done for any 'fs_root' argument in the archive methods.
>
> Point 2: the 'pause' argument moved from boolean to infinint.
>
>     replacing the boolean argument by the following expression will keep
> the same feature:
>
>         original_provided_boolean_argument ? 1 : 0
>
> (if true -> pause every 1 slice else do not pause at all)
>
> Point 3: root_EA and user_EA has been replaced by a mask 'ea_mask'.
> to keep the same behavior you have to build a mask as follows and use it
> in place of root_EA and user_EA:
>
>      ou_mask ea_mask; // build an empty mask that does the *or* operation
>
>      if(root_EA)
>         ea_mask.add(simple_mask("system.*"));
>      if(user_EA)
>         ea_mask.add(simple_mask("user.*"));
>      if(!root_EA && !user_EA) // if ea_mask is still empty
>         ea_mask.add(bool_mask(false));
>
>     // note that if ea_mask is empty (both root_EA and user_EA
>     // are false) you can avoid using an ou_mask object by directly
>     // using a bool_mask(false) object as argument (this does the same
>     // but will save some CPU cycles.
>
> Point 3: ignore_owner (boolean) has been replaced by 'what_to_check'
>     of type inode::comparison_fields, which is declared in catalogue.hpp.
>     here the equivalent behavior is realized by the following expression:
>
>      what_to_check = ignore_owner ? cf_ignore_owner : cf_all
>
>
> Point 4 : as opposed to point 1 to 3 that are general to the different
> public archive's class methods, this point does only apply to the
> 'create' constructor of archive class:
> between the 'same_fs' and the 'ret' argument (which is the last of this
> method), took place 4 new arguments corresponding to four new features:
>
> for backward compatibilty:
>
>     - snapshot (boolean), has to set to false
>     - cache_directory_tagging (boolean) has to be set to false also
>     - display_skipped (boolean) has to be set to false also
>     - fixed_date (infinit) has to be set to zero
>
> Point 5 : still in the same 'create' constructor, the last argument
> 'ret' has been changed of name ('progressive_report') and type (pointer).
>
> here, providing the address of the original argument (thanks to the &
> operator) will do the trick.
>
> Point 6 : archive::op_extract received a new argument 'ea_erase'.
> For backward compatibility set it to false. (Point 1 to 3 also apply to
> this method as well as point 5).
>
> Point 7 : archive::op_listing has seen the tar_format boolean argument
> been replaced by list_mode of type listformat.
>
>      listformat = tar_format ? normal : tree
>
> (I guess op_listing is not used in kdar, but...)
>
> Point 8 : archive::op_diff has point 1 to 3 and point 5 that do apply.
>
> Point 9 : archive::op_test has point 1, 3 and 5 that apply.
>
> Point 10 : the statistic type has been changed from struct to class
> the different field that were accessible directly before has to be
> read throw the get_*() methods. For example:
>
>    statistics_obj.treated
>
> has to be replaced by
>
>    statistics_obj.get_treated()
>
>
> That's all the changes I could found that are officially part of the
> API, I know however that Johnathan has used some useful tools from the
> tools.hpp/cpp module. No much change there, but rather several new
> functions have been added, but in case of problem here don't hesitate to
> ask me.
>
> I wish you success!
>
> Kind Regards,
> Denis.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api
>
>
>

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Denis C. <dar...@fr...>]

Glen Ogilvie wrote:
> 
> Dennis, have you managed to put togeather a summary of the API
> changes?  It would help in updating kdar to use them.
> 

Point 1: [taken from the ChangeLog and diff] :
    added -[ and -] options (file selection from file listing)
    Important consequence for libdar user programs:
    the fs_root argument is now expanded to full absolute path inside
    libdar, thus the mask you will give for path inclusion/exclusion
    (the "subtree" argument) will be used against full absolute path
    of files under consideration for the operation. Assuming you have
    fs_root=tmp/A and the current directory is /var/tmp, your mask will
    be used against strings like /var/tmp/A/some/file. (instead of
    tmp/A/some/file as in the previous API version). Things are equal
    if the fs_root is given an absolute path.

In other word, the fs_root argument (in all public archive's methods 
that use it) has to use become an absolute path, when user provides a 
relative path.

fs_root is an object of class path, the is_relative() method can let you 
  know whether a path is relative or not. If it is relative, find the 
current working directory (getcwd() system call for example) build a 
temporary path object (let's call it cwd_path) with the getcwd() string 
(constructor works with std::string that can be also built from char *) 
and before passing fs_root, set it to absolute with the path::operator+

     fs_root = cwd_path + fs_root;

This has to be done for any 'fs_root' argument in the archive methods.

Point 2: the 'pause' argument moved from boolean to infinint.

    replacing the boolean argument by the following expression will keep 
the same feature:

	original_provided_boolean_argument ? 1 : 0

(if true -> pause every 1 slice else do not pause at all)

Point 3: root_EA and user_EA has been replaced by a mask 'ea_mask'.
to keep the same behavior you have to build a mask as follows and use it 
in place of root_EA and user_EA:

     ou_mask ea_mask; // build an empty mask that does the *or* operation

     if(root_EA)
        ea_mask.add(simple_mask("system.*"));	
     if(user_EA)
        ea_mask.add(simple_mask("user.*"));
     if(!root_EA && !user_EA) // if ea_mask is still empty
	ea_mask.add(bool_mask(false));

    // note that if ea_mask is empty (both root_EA and user_EA
    // are false) you can avoid using an ou_mask object by directly
    // using a bool_mask(false) object as argument (this does the same
    // but will save some CPU cycles.

Point 3: ignore_owner (boolean) has been replaced by 'what_to_check'
    of type inode::comparison_fields, which is declared in catalogue.hpp.
    here the equivalent behavior is realized by the following expression:

     what_to_check = ignore_owner ? cf_ignore_owner : cf_all


Point 4 : as opposed to point 1 to 3 that are general to the different 
public archive's class methods, this point does only apply to the 
'create' constructor of archive class:
between the 'same_fs' and the 'ret' argument (which is the last of this 
method), took place 4 new arguments corresponding to four new features:

for backward compatibilty:

    - snapshot (boolean), has to set to false
    - cache_directory_tagging (boolean) has to be set to false also
    - display_skipped (boolean) has to be set to false also
    - fixed_date (infinit) has to be set to zero

Point 5 : still in the same 'create' constructor, the last argument 
'ret' has been changed of name ('progressive_report') and type (pointer).

here, providing the address of the original argument (thanks to the & 
operator) will do the trick.

Point 6 : archive::op_extract received a new argument 'ea_erase'.
For backward compatibility set it to false. (Point 1 to 3 also apply to 
this method as well as point 5).

Point 7 : archive::op_listing has seen the tar_format boolean argument 
been replaced by list_mode of type listformat.

     listformat = tar_format ? normal : tree

(I guess op_listing is not used in kdar, but...)

Point 8 : archive::op_diff has point 1 to 3 and point 5 that do apply.

Point 9 : archive::op_test has point 1, 3 and 5 that apply.

Point 10 : the statistic type has been changed from struct to class
the different field that were accessible directly before has to be
read throw the get_*() methods. For example:

   statistics_obj.treated

has to be replaced by

   statistics_obj.get_treated()


That's all the changes I could found that are officially part of the 
API, I know however that Johnathan has used some useful tools from the 
tools.hpp/cpp module. No much change there, but rather several new 
functions have been added, but in case of problem here don't hesitate to 
ask me.

I wish you success!

Kind Regards,
Denis.

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Denis C. <dar...@fr...>]

Glen Ogilvie wrote:
> Hi,

Hello Glen,

> 
> I would like to help with getting kdar working with the newer dar
> libraries.  I am a beginner C++  programmer, so will need help, but am
> prepared to spend  time learning and will put in some effort if anyone
> still reads this list.

Cool! That's something I had putted in my list of things to do, but you 
will save me some time doing it. Of course, you can rely on me (using 
this mailing-list) for any help.

I realized afterward that breaking backward compatibility of the API is 
not fair for applications that rely on it, while for some reasons I felt 
(and still feel) good I had to do it.

For the future, I cannot prevent that it will not occure again, but I 
will try to better reduce it and if not possible I will create a 
document that gather the changes to apply to each API call, to keep the 
same behavior, from one API version to the next API version. This will 
be done in a document rather than in this mailing-list for further 
reference and to be used by applications that rely on libdar.

> 
> I've been digging around in the source, but not finding it easy to
> figure out all the new stuff needed to be passed when using new
> libdar::archive in createArchiveThread.cpp.
> 

I see two possibilities to address your need:
- try to compile and look for the error messages
- do a "cvs diff" between the two API version (I will do it right now 
and provide you the interesting part).


> Also,
> 
> Denis Corbin wrote:
> 
>>  By the way, I have quite finished implementing the features I wanted to
>>  include in next major release that have impact on the API. There is one
>>  more feature (the "dar_merge") I have to make room for (a new
>>  constructor for the archive class) then I will freeze the API for new
>>  features. So you will be very welcome to integrate the new features
>>  brought by the next libdar if you like in kdar, eventually give your
>>  feedback for I add the necessary calls I could have not thought about
>>  for it works as you wish. Of course I will first have to give you a
>>  summary of what have changed since previous API and how to use it.
>>
>>  On the path to the release, few other feature are to be implemented that
>>  should not have impact on the API and documentation of the API should
>>  have to be updated, as well as I hope a review of the overall
>>  documentation structure.
>>
> 
> Dennis, have you managed to put togeather a summary of the API
> changes?  It would help in updating kdar to use them.

Yep, I will provide it to you ASAP.

> 
> Regards
> Glen Ogilvie
> New Zealand
> 

Thanks Glen,

Best Regards,
Denis.

[Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Glen O. <ne...@li...>]

Hi,

I would like to help with getting kdar working with the newer dar
libraries.  I am a beginner C++  programmer, so will need help, but am
prepared to spend  time learning and will put in some effort if anyone
still reads this list.

I've been digging around in the source, but not finding it easy to
figure out all the new stuff needed to be passed when using new
libdar::archive in createArchiveThread.cpp.

Also,

Denis Corbin wrote:
>   By the way, I have quite finished implementing the features I wanted to
>   include in next major release that have impact on the API. There is one
>   more feature (the "dar_merge") I have to make room for (a new
>   constructor for the archive class) then I will freeze the API for new
>   features. So you will be very welcome to integrate the new features
>   brought by the next libdar if you like in kdar, eventually give your
>   feedback for I add the necessary calls I could have not thought about
>   for it works as you wish. Of course I will first have to give you a
>   summary of what have changed since previous API and how to use it.
>
>   On the path to the release, few other feature are to be implemented that
>   should not have impact on the API and documentation of the API should
>   have to be updated, as well as I hope a review of the overall
>   documentation structure.
>
Dennis, have you managed to put togeather a summary of the API
changes?  It would help in updating kdar to use them.

Regards
Glen Ogilvie
New Zealand

Re: [Dar-libdar_api] libdar version 3

[Denis C. <dar...@fr...>]

Khoem Sokhem wrote:
> Hi,

Hello,

> 
> I translated Kdar into Khmer 100% completed and I start running
> ../configure - make- make install , then the application still in English.
> I have read the INSTALL file and said that require libdar version 3.0.
> Where should I get this version?

please checkout the "cross reference matrix" in the dar documentation
which is available here:
http://dar.linux.free.fr/doc/index.html#Dar_version_naming

looking in the "libdar" column you will see that libdar version 3.0.0 
has been released under 2.2.0 version, and that the latest and most 
stable libdar in version 3.0.x is version 3.0.2 which can be found in 
the dar source package release 2.2.2

to download source package check the documentation here:
http://dar.linux.free.fr/doc/index.html#Downloading


> 
> 
> Your reply is important for me!
> 
> Thanks,
> Sokhem
> 


Kind Regards,
Denis.

[Dar-libdar_api] libdar version 3

[Khoem S. <kho...@kh...>]

Hi,

I translated Kdar into Khmer 100% completed and I start running
./configure - make- make install , then the application still in English.
I have read the INSTALL file and said that require libdar version 3.0.
Where should I get this version?


Your reply is important for me!

Thanks,
Sokhem

Re: [Dar-libdar_api] specifying ea_mask

[Denis C. <dar...@fr...>]

Will Stephenson wrote:
> Hi list

Hello,  (and sorry for the moderation overhead)

> 
> I'm trying to update kdar(*) to work with libdar 4.0.0 and have run into a 
> block 
> in the plain libdar::archive ctor.  
> 
> I see that root_ea and user_ea args have been replaced by ea_mask, which must 
> perform the same function, but I have no idea how to specify the 
> equivalent "ignore user EA"/"ignore system EA" options using ea_mask.

well, that's not that complicated, but that's true there is a lack of 
documentation on that point:

The ea_mask argument receives as argument a mask that defines which EA 
(based on the "domain.name" expression) will be considered or not. This 
is exactly as what can be found for file selection with file "subtree" 
and "selection" arguments that correspond to the -P/-g/-[/-] options for 
the first one and to the -X/-I options for the second one.

Thus, if you want to only consider user EA, you should give for example 
a simple_mask("user.*") or a regular_mask("^user\..*") as ea_mask 
argument to libdar.

if you want to ignore all EA, simply pass a bool_mask(false) as argument.

if you want to consider all EA, simply pass a bool_mask(true) as argument.

If you want to only consider system EA, the argument to pass can be for 
example a simple_mask("system.*").

for the negation like "ignore user EA", you need to build a negation 
this is done passing as argument the following object: 
not_mask(simple_mask("user.*"))


>  I've 
> poked around in the command_line.* sources but it seems the string for the 
> ignore/allow EAs comes from the command line, and I can't find an example or 
> documentation for this, 

EA have a structured name, where the first part is the domain ("system", 
  "user", "security", and so on), and the second part is the EA's name 
in that domain. Theses two parts are separated by a dot. Full EA format 
required by the system (and against which libdar makes comparisons) is 
thus of the form:

    user.my_own_EA
    system.some_other_EA
    security.yet_another_one


>the only masks I can find refer to extended file 
> permissions, which as I understand it are a subset of EAs.

well I guess no. Masks make a generic class hierarchy that work on 
strings. In one side a mask is build and pass to libdar. Libdar then, in 
the other side, presents to this mask each string it has to take an 
action on, the masks answer "true" or "false" for each presented string, 
and libdar take subsequent action (exclude/include file, exclude/include 
file or directory, exclude/include EA).

> 
> Put simply: 
> 
> A What's the mask for "all user EA"?

simple_mask("user.*")

> 
> B What's the mask for "all system EA"?

bool_mask(true)

> 
> C What's A & B?

and_mask tmp;
tmp.add(A);
tmp.add(B);


> 
> D What's !A & !B ?

and_mask tmp;
tmp.add(not_mask(A));
tmp.add(not_mask(B));

> 
> Can anyone enlighten me?

please refer to the libdar/mask.hpp file for full available mask from 
libdar. Note that you may also create your own mask by inheritance from 
an already defined mask class.

> 
> Thanks
> 
> Will
> 
> * Just a minimal update so it preserves the same behaviour with the new 
> libdar, no new features. 

Yes, I understand. I guess Johnathan will have some time soon or later 
to update kdar more deeply with new features. ;-)

Kind Regards,
Denis.

[Dar-libdar_api] specifying ea_mask

[Will S. <wst...@su...>]

Hi list

I'm trying to update kdar(*) to work with libdar 4.0.0 and have run into a 
block 
in the plain libdar::archive ctor.  

I see that root_ea and user_ea args have been replaced by ea_mask, which must 
perform the same function, but I have no idea how to specify the 
equivalent "ignore user EA"/"ignore system EA" options using ea_mask.  I've 
poked around in the command_line.* sources but it seems the string for the 
ignore/allow EAs comes from the command line, and I can't find an example or 
documentation for this, the only masks I can find refer to extended file 
permissions, which as I understand it are a subset of EAs.

Put simply: 

A What's the mask for "all user EA"?

B What's the mask for "all system EA"?

C What's A & B?

D What's !A & !B ?

Can anyone enlighten me?

Thanks

Will

* Just a minimal update so it preserves the same behaviour with the new 
libdar, no new features. 

[Dar-libdar_api] Re: Thread-safe not initialized for libdar

[Denis C. <dar...@fr...>]

Arun Sharma wrote:
> Hi,, All

Hello,

> 
> After compiling my program and executing it gives below messgae.
> 
> ERROR :
> 
> # ./executing-program
> Thread-safe not initialized for libdar, read manual or contact 
> maintainer of the application that uses libdar

You have probably not called the libdar::get_version() function, for 
more, have a look at the API tutorial, there a good example on how your 
program has to check the values returned by libdar::get_version() and 
what comportment your program has to adopt in case of version mismatch.

> 
> 
> 
> Can any body have the idea for the above errror.
> 
> Please give detailed info ,, if any body have
> 
> reards
> 

Regards,
Denis.

[Dar-libdar_api] Thread-safe not initialized for libdar

[Arun S. <ar...@gm...>]

Hi,, All

After compiling my program and executing it gives below messgae.

ERROR :

# ./executing-program
Thread-safe not initialized for libdar, read manual or contact maintainer o=
f
the application that uses libdar



Can any body have the idea for the above errror.

Please give detailed info ,, if any body have

reards

[Dar-libdar_api] Time to freeze the API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

There is now quite one year that took place the last major release,
since that time a lot of new features took place in the development
version. Some more have to come yet, but it is time to make theses
already implemented become a bit more public, so we are now on the way
to the next major release: version 2.3.0. / API 4.0.0

For today The API is frozen, so you have several weeks to report
problems in its design, things I could have missed as my point of view
is not really the one of a full user of the API like kdar is. The API
Tutorial is almost up to date, some arguments are missing in regards to
the two latest features used, but doxygen should bring you all
information needed.

I let you refer to the "Changes" file in CVS trunk, to see the list of
new features and their impacts on the API. If something is not clear and
not enough detailed don't hesitate to send an email to the libdar-API
mailing-list.

In the meanwhile I have a big work to do with documentation, depending
on my free time, I hope to finish before end of January. Then would come
the traditional one-month-pre-release phase that would end up with the
2.3.0 release.

Thanks to all for your patience, feedback, suggestions and encouragements.

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDlIEXpC5CI8gYGlIRAgW5AJ4nz1IvJs+uGBG6TvSJ9Xy2yLp1lACfZZxT
/+g9snMHXuV23TKCdMrIGuc=
=00bI
-----END PGP SIGNATURE-----

[Dar-libdar_api] Re: adding encrypted archive to database

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| On Thursday 29 September 2005 19:57, Johnathan Burchill wrote:
|
|>Hi Denis,

Hello Johnathan,

|>
|>How does a client program add an encrypted archive to a database?
|>Is this possible under the current/planned API?
|
|
| Never mind! Your TODO answers my question :)

:-)

By the way, I have quite finished implementing the features I wanted to
include in next major release that have impact on the API. There is one
more feature (the "dar_merge") I have to make room for (a new
constructor for the archive class) then I will freeze the API for new
features. So you will be very welcome to integrate the new features
brought by the next libdar if you like in kdar, eventually give your
feedback for I add the necessary calls I could have not thought about
for it works as you wish. Of course I will first have to give you a
summary of what have changed since previous API and how to use it.

On the path to the release, few other feature are to be implemented that
should not have impact on the API and documentation of the API should
have to be updated, as well as I hope a review of the overall
documentation structure.

|
|
|>Cheers,
|>JB
|
|


Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDPagFpC5CI8gYGlIRAiQNAJ4hW5taVChIYuiDHcjxlsk1QtkdsQCgv/Sp
Q1VrMbaVpAeEFm+Oxtq7VrI=
=lJRj
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] adding encrypted archive to database

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

On Thursday 29 September 2005 19:57, Johnathan Burchill wrote:
> Hi Denis,
>
> How does a client program add an encrypted archive to a database?
> Is this possible under the current/planned API?

Never mind! Your TODO answers my question :)

>
> Cheers,
> JB

-- 
Johnathan K. Burchill
jk...@co...

[Dar-libdar_api] adding encrypted archive to database

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

Hi Denis,

How does a client program add an encrypted archive to a database? Is 
this possible under the current/planned API?

Cheers,
JB

-- 
Johnathan K. Burchill
jk...@co...

[Dar-libdar_api] API 3.x.x versus API 4.x.x about file filtering

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I have noted a side effect for the addition of a new mask class in
libdar: the class "mask_list". This mask class takes a list of file to
match, from a given file, this list may contain relative path as well as
absolute paths (which is new to libdar).

To be able to compare absolute paths, the dar's root directory in which
takes place all the file operations when saving, extracting and
comparing, directory which is passed under the "fs_root" argument of the
corresponding methods of class archive, well, this root has to be
expanded to an absolute path when a relative path is given:

Assuming the current directory is /var/tmp and your program calls libdar
giving A/test as value to the "fs_root" argument (-R option for dar),
this argument will be expanded to /var/tmp/A/test inside libdar.

The side effect is that when scanning the directory tree the strings
passed to the mask for matching are no more of the type A/test/some/file
as it was in the API 3.x.x but /var/tmp/A/test/some/file.

The consequence is that when building the masks before calling libdar
for a call that uses the "subtree" argument you must consider this root
expansion to an absolute path. For example, the user gives:
~   fs_root = A/test  ([-R A/test] with dar)
~   current directory is /var/tmp
~   the user asked for excluding A/test/B subdirectory ([-P "B/toto"]
with dar).
~   then you must build mask that exclude "/var/tmp/A/test/B/toto"
instead of "A/test/B/toto". Note that you can still pass to libdar
relative paths as value for fs_root, it will be expanded by the value
returned by the getcwd() system call.

Last point concerns the op_listing() operation. This method does not
have a "fs_root" argument because no operation is done in the filesystem
(just listing the archive contents), however this methods *has* a
"subtree" argument, allowing one to prune some directories from the
listing. Masks must thus be done considering that a virtual "fs_root"
argument has been given the "<ROOT>" value. In consequence, masks will
be applied strings like "<ROOT>/some/files". This is not new, release
3.x.x had the same "feature", that no one seems to have noticed, since
graphical applications usually do not use the op_listing() method, but
prefer the get_children_of() method.

I have updated the api_tutorial with a similar note, and a sparse not in
the comments used for Doxygen.

Cheers,
Denis.

P.S.: nothing is changed for the selection arguments (-I, -X options for
dar) nor for the compression mask (-Y -Z options for dar).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDBkUnpC5CI8gYGlIRAsJqAKCGdGrhWV3A/90neJASDm61eXfr6QCgjB7d
+/GdzKxCxapLDftLyv7uqmo=
=RgO1
-----END PGP SIGNATURE-----

[Dar-libdar_api] Re: dar_manager API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Corbin wrote:
| Johnathan Burchill wrote:
| | Hi Denis,

Hello Johnathan,

|
| Hello Johnathan,
|
| [...]
|

[...]

| |
| | The point is that there is nothing in the API which lets me get access
| to a
| | catalogue. I expected add_archive to accept a pointer to an archive
| object,
| | or an archive object to have an accessor to its catalogue which can
| then be
| | passed to add_archive. The macro_tools_get_catalogue() function is not
| | actually part of the public API, and a given archive's cat member is
| | private.
|
| OK, I see now. Yes, this is a problem that can be solved by replacing
| the "catalogue" argument with a "archive" argument (and appropriated
| adaptation within the call). I will fix that, thanks for feedback.

Well, this is fixed now: There is no more a "catalogue" argument in the
API for dar_manager. Thanks for your feedback. :-)

|
[...]

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDAkATpC5CI8gYGlIRAovhAKCkIKzRmJ2DiXZbi9sv9Wu6lVqo8wCgofUW
htod0lvv657KnP8IRjXnxrg=
=UZlw
-----END PGP SIGNATURE-----

[Dar-libdar_api] Callback functions in libdar

[Michael R. <mi...@da...>]

Hi all,

I have a question I hope on of you can help me with:

First a piece of the source code:
/*
** Display a warning to the user in a GtkMessageDialog
** Input:
**    void *: Gpointer to the main window
**    GtkMessageType: The type of message dialog
**    const gchar *: The message to display in the dialog
**
** Output:
**    Cancel clicked: GTK_RESPONSE_CANCEL
**    Ok clicked: GTK_RESPONSE_OK
*/
GtkResponseType ok_cancel_message(
	void *mainwindow, GtkMessageType type, const gchar *msg)
{
	GtkWidget		*dialog;
	GtkResponseType    result;
	=20
	dialog =3D gtk_message_dialog_new (
		(GtkWindow *) mainwindow,
         (GtkDialogFlags) (GTK_DIALOG_DESTROY_WITH_PARENT |
GTK_DIALOG_MODAL),
         type,
         GTK_BUTTONS_OK_CANCEL,
	msg);
	result =3D (GtkResponseType) gtk_dialog_run(GTK_DIALOG (dialog));
	gtk_widget_destroy(dialog);
	return result;
}

bool answer_callback(const string &message, void *context)
{
	GtkResponseType  result;
	=20
	result =3D ok_cancel_message(context, GTK_MESSAGE_WARNING,
message.c_str());
	if (result =3D=3D GTK_RESPONSE_OK)
		return true;
	else
		throw Euser_abort(NULL);
}

The answer call back is called when slices exists and the
user has choosen to create a new backup set. The
ok_cancel_message is shown and if the user hits Ok the
creating of the backup set begin. Now comes the problem: all
though the gtk_widget_destroy(dialog) is called before
returning the call it is blocked until the creation of the
archive is finished. Does anyone have an idea how I can bypass
this state?

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Tonight's the night: Sleep in a eucalyptus tree.

[Dar-libdar_api] Re: dar_manager API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| Hi Denis,

Hello Johnathan,

[...]

|>
|>Well, maybe I don't properly understand your remark, but, if this is
|>called from within add_archive() directly, what would you give to
|>add_archive(), a filename and path? right? So you cannot use an
|>catalogue from memory. Suppose you make a backup and want to add it
|>automatically to a dar_manager database. If using a filename, you will
|>not be able to use the catalogue in memory but instead will have to load
|>it from just written file...
|>
|
|
| The point is that there is nothing in the API which lets me get access
to a
| catalogue. I expected add_archive to accept a pointer to an archive
object,
| or an archive object to have an accessor to its catalogue which can
then be
| passed to add_archive. The macro_tools_get_catalogue() function is not
| actually part of the public API, and a given archive's cat member is
| private.

OK, I see now. Yes, this is a problem that can be solved by replacing
the "catalogue" argument with a "archive" argument (and appropriated
adaptation within the call). I will fix that, thanks for feedback.


Back to your other remark where you ask why dar_manager relies on dar
command-line and not directly on libdar? The reason is that dar_manager
must do the command-line parsing exactly as dar does, so if I don't want
to duplicate this dar code in dar_manager, I must share it between
theses two programs, but I cannot share it through libdar because libdar
must not receive such command-line related functions. I could, yes, link
dar_manager with the dar's command_line.o object file outside of libdar,
but that would not bring any improvment, just it would avoid creating a
shell from where to run dar.


|
| Regards,
| JB
|
|

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFC87ywpC5CI8gYGlIRArAoAKCpJ+rWerGMUDGviue0vDmUxuOIxgCfWqgy
uZYZK45QbjRA7jiygZgaoFk=
=JkSO
-----END PGP SIGNATURE-----

[Dar-libdar_api] Re: dar_manager API

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

Hi Denis,

Denis Corbin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Johnathan Burchill wrote:
> | Hi Denis,
> |
> 
> Hello Johnathan,
> 
> Sorry for the late reply, I have a ISP problem for now, and could only
> now find an old modem to have a temporary backup solution to connect to
> Internet. :-/

Too bad, but whatever works...

> 
> | I hope things are well with you.
> 
> yes, over this ISP problem, thanks. :-)
> 
> | I'm settled in the U.S. and now have some
> | time to think about dar/kdar.
> 
> Cool, I hope you realize how lucky you are!  :-)

I'm doing okay :).

> 
> | Glad to see you've made the move to have
> | dar_manager in the API. While it looks like you haven't made an official
> | announcement yet, I'll comment and ask questions anyway.
> 
> Yes, this is recent, the "Changelog" is always up to date. Your comments
> are welcome, as well as other's.
> 
> |
> | The API includes functions for manipulating the path to the dar binary.
> | Shouldn't the database object just call libdar functions directly
> through the
> | API?
> 
> Well, This must be considered. There might be some historical reasons
> that let to that situation (dar_manager appeared before libdar).
> 
> |
> | add_archive(...) requires a catalogue reference. It seems akward from a
> | developer point of view: macro_tools.hpp has to be included in order
> to use
> | the "macro_tools_get_catalogue_from()" helper to get the catalogue. This
> | could be called from within add_archive() directly, no?
> 
> Well, maybe I don't properly understand your remark, but, if this is
> called from within add_archive() directly, what would you give to
> add_archive(), a filename and path? right? So you cannot use an
> catalogue from memory. Suppose you make a backup and want to add it
> automatically to a dar_manager database. If using a filename, you will
> not be able to use the catalogue in memory but instead will have to load
> it from just written file...
> 

The point is that there is nothing in the API which lets me get access to a
catalogue. I expected add_archive to accept a pointer to an archive object,
or an archive object to have an accessor to its catalogue which can then be
passed to add_archive. The macro_tools_get_catalogue() function is not
actually part of the public API, and a given archive's cat member is
private.

Regards,
JB

> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
-- 
Johnathan K. Burchill, Ph.D.
jk...@co...

[Dar-libdar_api] Re: dar_manager API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| Hi Denis,
|

Hello Johnathan,

Sorry for the late reply, I have a ISP problem for now, and could only
now find an old modem to have a temporary backup solution to connect to
Internet. :-/

| I hope things are well with you.

yes, over this ISP problem, thanks. :-)

| I'm settled in the U.S. and now have some
| time to think about dar/kdar.

Cool, I hope you realize how lucky you are!  :-)

| Glad to see you've made the move to have
| dar_manager in the API. While it looks like you haven't made an official
| announcement yet, I'll comment and ask questions anyway.

Yes, this is recent, the "Changelog" is always up to date. Your comments
are welcome, as well as other's.

|
| The API includes functions for manipulating the path to the dar binary.
| Shouldn't the database object just call libdar functions directly
through the
| API?

Well, This must be considered. There might be some historical reasons
that let to that situation (dar_manager appeared before libdar).

|
| add_archive(...) requires a catalogue reference. It seems akward from a
| developer point of view: macro_tools.hpp has to be included in order
to use
| the "macro_tools_get_catalogue_from()" helper to get the catalogue. This
| could be called from within add_archive() directly, no?

Well, maybe I don't properly understand your remark, but, if this is
called from within add_archive() directly, what would you give to
add_archive(), a filename and path? right? So you cannot use an
catalogue from memory. Suppose you make a backup and want to add it
automatically to a dar_manager database. If using a filename, you will
not be able to use the catalogue in memory but instead will have to load
it from just written file...

|
| Cheers,
| JB


Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFC6+hcpC5CI8gYGlIRAu6qAJ9X+bRkDRrFXq3vsCF6rUyCCAE24QCgrZTP
Q48/7No2B+c3RyaAKsiG1LU=
=kM4E
-----END PGP SIGNATURE-----