Package Details: dar 2.5.14-2

Git Clone URL: (read-only)
Package Base: dar
Description: A full featured command-line backup tool, short for Disk ARchive
Upstream URL:
Keywords: archive backup dar disk
Licenses: GPL
Submitter: xyproto
Maintainer: MarcinWieczorek
Last Packager: MarcinWieczorek
Votes: 46
Popularity: 0.016798
First Submitted: 2011-12-14 16:48
Last Updated: 2018-04-08 11:00

Latest Comments

DrMartinus commented on 2017-04-17 06:30

I get the errorcode 8 somewhere in the middle of the backup, probably because of the amount of files to be packed in the archive. Explanation according to man-page:

"the version of dar used is based in finite length integers (it has been compiled with the option --enable-mode=...). This code is returned when an integer overflow occurred. use the full version (based in the so called "infinint" class) to avoid this error."

The so far finished archive has about 160 GB in around 40 slices, RAM is no problem.

ralley commented on 2017-02-16 11:45

With the --enable-mode=64 compile flag, I get the error "Cannot handle such a too large integer." Without this flag it is working. The backup size is about 5 GB (no zetabytes!). The memory usage without this flag is about 250 MB. I think this is not so much, so please consider to remove this flag again.

MarcinWieczorek commented on 2017-02-09 07:24

Contact me via email or XMPP (same address) if you want to become a co-maintainer.

DrMartinus commented on 2017-02-09 06:18

I would adopt it, if I knew how. Since I use the software frequently, I can also test it.
I guess, that wasn't necessary, since it seems Marcin Wieczorek being the maintainer? In that case: I eagerly await version 2.5.9, since I am struggling with a bug that's supposed to be solved with that new release.
I would appreciate it being made available soon... ;-)

MarcinWieczorek commented on 2016-10-22 15:48

I didn't see that the pkgrel is equal 2 :(

izmntuk commented on 2016-06-01 15:46

Disowned as I no longer have enough time for maintenaunce. (and I cannot access a environment for testing the new release now...) So feel free to adopt it if you are interested.

flyingDavid commented on 2016-02-19 17:24

Could you please re-add the --enable-mode={64,32} compile flags?
After removing them, dar uses a special integer format to store arbitrary big integers, but this needs much more memory for me (We're talking about gigabytes here)
This is needed for backups of zetabytes of data [1], but I guess that's much more than most of the users need.


encbladexp commented on 2014-12-29 16:46

Yes, samples and docs should be in /usr/share/doc/dar, and not in /usr/share/dar ;)

Fixing your /etc/darrc should work, maybe i fix this with the next package update so /etc/darrc points to the right destination for new installations.

MONOmah commented on 2014-12-24 03:52

Integration with par seems to be broken. And anything else, that require files in /usr/share/dar. These files really reside in /usr/share/doc/dar.

svg1234 commented on 2014-04-11 19:51

Just a note to anyone w/ the i686 o/s considering doing the build w/ 32 bit integers: 1) The infinint is quite a bit slower than the int32, so if you an use int32, it is worth it. 2) If you do use int32, not only is the archive limited to 4GB per slice, but if you plan on using encryption you will not be able to restore in certain cases! It depends on how many files have in the encrypted datase. The encryption works fine, but when you try to restore your files...DAR will issue an "out of memory" error.

(I will be upgrading my o/s to 64 bit over the weekend in order to use int64 w/ DAR).

encbladexp commented on 2014-04-11 17:48


I upload this with the next dar release.

svg1234 commented on 2014-04-11 01:52

"You also might want to speed up the compilation process running ./configure
with the --disable-static option".

Might want to add --disable-static to the pkgbuild?

svg1234 commented on 2014-04-11 00:36

re: the 4GB, I found out it's for the ARCHIVE size. I tested a backup w/ low compression, and it went over 4GB, and then erred out.

I have a 64 bit cpu but only 2GB ram (don't need 64 bit to address memory), so a couple of years ago when I did my original arch install, I went with the 32 bit. One of these days I'll get around to switching to the 64 bit version.

I guess I'll try infinint and see what the difference is versus the 32 bit integer build that I did last night. I currently have about 120K files on my system. I have plenty of swap space, so that isn't an issue. Guess it just comes down to speed.


raw commented on 2014-04-10 05:55

i dont know, as i havent tried it on 32 bit os, so almost everything i write here is speculation.

IMHO, as a 32 bit linux-kernel is actually built for a 32 bit machine, it does not allow access to 64 bit operations. If you have a 64 bit CPU, there is no reason to not use a 64 bit Linux.

While i still dont know exactly, i think your whole backup can be larger than 4GB. In worst case you have to split your archive into multiple slices. Just give it a try, if you hit any limit, DAR will tell you. If you do not have many files to backup, you are probably fine with infinitint anyways. If you are backing up millions of files (like E-Mails, many many images) AND want to use dar_manager, i strongly recommend a 64 bit OS, as it makes a serious difference in memory usage and performance.

This integer-mode also applies to the dar_manager, so the maximum file count applies to the dardb-archive too. if you have 1,000,000 files per backup and use dar_manager for easy restore, your dardb could only cover 4 backups until the file limit is hit.

svg1234 commented on 2014-04-10 02:37


Is the 64 bit integer mode only for a 64 bit O/S? I have a 64 bit cpu but have arch i686 (32 bit) installed. Can I use the 64 bit integers? Probably not.

svg1234 commented on 2014-04-09 23:34

1) Is the 64 bit integer mode only for the 64 bit O/S? I have a 64 bit cpu but use arch i686 (32 bit). Is it the cpu or the o/s that matters? Can I use the 64 bit integers?

2) Is the 4gb file size limit (for 32 bit integer) for each SOURCE file? Or is it a 4GB overall limit for the archive that DAR produces? I don't have any individual files that are > 4GB but my system backup will be > 4GB.

encbladexp commented on 2014-04-09 13:29

Hi raw,
nice Idea => Done. Thx!

raw commented on 2014-04-09 11:28

Hello encbladexp,

i suggest to change the PKGBUILD to enable 64-Bit integer mode on 64 bit Systems by default:

if test "$CARCH" == x86_64; then

./configure --prefix=/usr --sysconfdir=/etc $EXTRA_OPTIONS

im using dar on a large fileset that cannot behandled with the default infinitint. While on 32 bit Systems, infinitint avoids the 4GB file size and 4,294,967,296 file count limit, i can't imageine any dar user to hit the 64 bit Limits.
Using infinitint creates a lot of memory and cpu overhead, making it impossible to backup a large amount of files with infinitint. I have to recompile dar every update and would like to see the 64 bit mode default on 64 bit Systems. Thank you.

hamelg commented on 2012-07-01 09:05

encbladexp commented on 2012-07-01 07:37

Hi, you should downgrade to 2.4.5 and contact the dar developers about this issue.

hamelg commented on 2012-06-29 21:03

upgraded dar (2.4.5-1 -> 2.4.6-1) yesterday
today backup is failed :(
Skipping file: /home/tabelg/.gnom*** glibc detected *** dar: free(): invalid next size (fast): 0x103f49d0 ***
======= Backtrace: =========

Anonymous comment on 2012-04-09 19:48

This PKGBUILD requires a couple of fixes:

1) Prevent a build failure in src/libdar/secu_string.cpp with gcc-4.7.0
Patch that file to #include <unistd.h> (I suggest before #include "../my_config.h").

2) Fix an exception that occurs with dar -l for a dynamically linked dar
On the ./configure command do one of the following:

i) Add --mode=32 or --mode=64
ii) Add --disable-special-alloc

Option (i) is for a specific 32-bit or 64-bit optimized build of dar
Oprion (ii) is a generic solution which is less optimal but works for either arch

Both of these issues will be addressed in dar-2.4.5. The developer fixed item (2) with access to my Arch system.

Anonymous comment on 2012-03-29 13:40

This seems to be a problem with 2.4.4. I modified the PKGBUILD to build 2.3.12 and that version works fine.

Anonymous comment on 2012-03-29 11:17

If you execute dar -l on an existing archive the output shows unhandled exceptions occurring.

xyproto commented on 2011-12-14 16:50

Moved from [community] in connection with the Christmas Cleanup