Re: DAR format questions

gulikoza wrote:
> Hello,

Hello,

>  
> I am writing a DAR Total Commander plugin. I have managed to get basic 
> browsing and decompression done, creating my own implementation for dar 
> handling (thanks to Wesley Leggette's documentation). But I have a few 
> questions...
>  
> 1. In the docs, ea flag is specified as
>  
> "1 byte inode flag; values are ``ea_none = 0x00`` when no Extended 
> Attributes are stored, ``ea_partial = 0x01`` when partial Extended 
> Attribute information is stored, ``ea_full = 0x02`` when Extended 
> Attributes are fully stored."

well, format has changed several time (current is revision 5) and thing 
may change again as new feature get added. This documentation is thus a 
bit out of date.


>  
> I don't have many testcases but I'm getting mostly 0x03 when no EA is 
> present and 0x01 in an archive that seems to have full EA present. What 
> are the correct values then?

For that you'd better grap from source code (src/libdar/catalogue.cpp):

#define INODE_FLAG_EA_MASK  0x07
#define INODE_FLAG_EA_FULL  0x01
#define INODE_FLAG_EA_PART  0x02
#define INODE_FLAG_EA_NONE  0x03
#define INODE_FLAG_EA_FAKE  0x04


>  
> 2. Incremental backups have different signatures that are not 
> documented. I'm seeing 'D' (0x44) for directories and 'F' (0x46) for 
> files. How are these supposed to be handled?

Here too, better grap from source code (src/libdar/catalogue.cpp):

  unsigned char mk_signature(unsigned char base, saved_status state)
     {
         if(! islower(base))
             throw SRC_BUG;
         switch(state)
         {
         case s_saved:
             return base;
         case s_fake:
             return base | SAVED_FAKE_BIT;
         case s_not_saved:
             return toupper(base);
         default:
             throw SRC_BUG;
         }
     }



>  
> Thanks,

No problem, but I don't understand why you are not using libdar's API 
rather than reinventing the wheel... First, you may miss some 
compatibility issue with older archive format, second you will have to 
track any new feature code and reimplement it on you own... while you 
could just link you plugin to libdar (either statically or dynamically) 
and call its functions thanks to its well defined API. Moreover you will 
have support for new features and bug fixes without much change for your 
plugin.

>  
> gulikoza
> 

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-discussions mailing list
Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/dar-discussions

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

iD8DBQFFJsNWpC5CI8gYGlIRAtbPAJ9bZR4ueEl5Yh0jazK5hK3MH0FPMACgqOVH
5BYD6A1bxxdgQW3t1zsov1w=
=qVjL
-----END PGP SIGNATURE-----