DAR's Documentation


This is the summary page for dar's documentation
    1. Presentation
    2. Obtaing dar/libdar
    3. Command-line tools usage
    4. Libdar and its API
    5. Dar/libdar internals
    6. Actions

1 - Presentation

2 - Obtaining dar/libdar

3 - Command-line tools usage

Dar's command-line tools is set of six command-line. Since release 2.0.0, dar source code has been split in two parts, one is command-line specific, the second is the libdar library with its API (application interface). But both parts stay released under the same package. The command-line tools relies on libdar to manage dar archives. Some other external tools do also use dar or libdar, to provide additional features or other interfaces like a Graphical User Interface. Here we will see how to use the dar command-line tools, see external tools respective documentation for more details about their usage.

You are invited to read the following documents:
If you lack some information from the previous documents, you are welcome to ask for support

4 - Libdar and its API

Libdar has (I hope) a well documented interface that let you access dar's features from your program. Libdar is written in C++ thus you have either to use C or C++ or use existing bindings for the language of your choice.

You are invited to read the following documents in order, up to the time you get enough information to address your need. Most of the time the two first source of information should be enough, but don't hesitate to subscribe to libdar-api mailing-list if some points are not clear about the API and the way to use it.

5 - Dar's internals

If you want to know more about the way dar is implemented you can read the  dar/libdar internals notes. The dar-discussion  mailing-list is also a place where discussions about the current implementation, alternative way of doing and future evolution of dar are welcome.

6 - Actions

Important : I no longer answer support requests made by email directly addressed to me. The reason is simple: posting your request in a public area (like the dar-support mailing-list), makes it visible to anyone. Answers to your problem might concern other people, and so a public area is the best place for answers to reside as well. I do not have as much time as I wish to develop DAR (adding new features and porting to new systems), so keeping support public will save me a little time, since it avoids me repeating the same answers to the same questions.
 Sharing must be both directions.

Stay informed about dar/libdar events

You can subscribe to the dar-news mailing-list, which is a read-only mailing-list that has a very low email volume (in average, less than one a month), to be informed about major events like new releases or security issues.

Asking for support

If FAQ, tutorial, mini-howto, usage notes, or man page do not answer your question, you can read the dar-support mailing-list archive at gmane, and use the search engine (the green text box at the bottom of the page) to look for keywords that match your problem. If that still does not solve your problem, you can subscribe to dar-support mailing-list and send an email to the mailing-list describing your issue.

Reporting a Bug

First, check that the problem has not already been seen and addressed in dar-support mailing-list. Then, check the Bug Tracker to see whether the bug has not already been reported (thanks to avoid duplicated). If found, you can monitor the corresponding item to be informed of any update concerning this bug. If the item is fixed you can grab the source code with the fix from GIT. But if the bug you met is not yet reported feel free to create a new report providing as much information and details as you can to ease reproducing and fixing the bug.
    Note that you need to register at Sourceforge to be able to open a bug (subscription to Sourceforge is free, and won't spam your email: I use it since 2002 and never got spam on the email I gave and which is only known by sourceforge). Giving a real email address is beneficial, because you'll get a notification when the status of the bug changes (like when it has been resolved) it also avoids me wasting time trying to reproduce a bug reported anonymously and impossible to reproduce (real bug with very little information, user mistake, ...).

Asking for a new feature

Use the New Feature tracker, first checking that no one has already thought about the request you are about to ask (thanks to avoid duplications). Note that the ability to ask a feature does not mean an obligation for me to implement it, in particular if the feature is not compatible with an already existing feature.

Submitting a patch

Feel free to use the Patch Tracker at Sourceforge.