dar-libdar_api

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

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)

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

[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