Package Details: dar 2.7.15-1

Git Clone URL: https://aur.archlinux.org/dar.git (read-only, click to copy)
Package Base: dar
Description: A full featured command-line backup tool, short for Disk ARchive
Upstream URL: http://dar.linux.free.fr/
Keywords: archive backup dar disk
Licenses: GPL
Submitter: xyproto
Maintainer: MarcinWieczorek
Last Packager: MarcinWieczorek
Votes: 56
Popularity: 0.103623
First Submitted: 2011-12-14 16:48 (UTC)
Last Updated: 2024-07-01 11:50 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

svg1234 commented on 2014-04-11 01:52 (UTC)

"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 (UTC)

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. Thanks.

raw commented on 2014-04-10 05:55 (UTC)

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 (UTC)

raw, 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.

encbladexp commented on 2014-04-09 13:29 (UTC)

Hi raw, nice Idea => Done. Thx!

raw commented on 2014-04-09 11:28 (UTC)

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 EXTRA_OPTIONS="--enable-mode=64" fi ./configure --prefix=/usr --sysconfdir=/etc $EXTRA_OPTIONS See http://dar.linux.free.fr/doc/Limitations.html#Integers 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 (UTC)

http://article.gmane.org/gmane.comp.sysutils.backup.dar.support/2543

encbladexp commented on 2012-07-01 07:37 (UTC)

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

hamelg commented on 2012-06-29 21:03 (UTC)

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: ========= /lib/libc.so.6(+0x72632)[0xb7355632] /usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb74ea8af] /usr/lib/libstdc++.so.6(_ZdaPv+0x1b)[0xb74ea8fb] /usr/lib/libdar.so.5000(_ZN6libdar5crc_n7destroyEv+0x29)[0xb76cf409] /usr/lib/libdar.so.5000(_ZN6libdar5crc_nD0Ev+0x2d)[0xb76d072d] /usr/lib/libdar.so.5000(_ZN6libdar4file7detruitEv+0x87)[0xb75e2ff7] /usr/lib/libdar.so.5000(_ZN6libdar4fileD0Ev+0x31)[0xb76020b1] /usr/lib/libdar.so.5000(_ZN6libdar9directory5clearEv+0x37)[0xb75f2fc7] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD1Ev+0x31)[0xb75f3101] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD0Ev+0x22)[0xb75f3192] /usr/lib/libdar.so.5000(_ZN6libdar9directory5clearEv+0x37)[0xb75f2fc7] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD1Ev+0x31)[0xb75f3101] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD0Ev+0x22)[0xb75f3192] /usr/lib/libdar.so.5000(_ZN6libdar9directory5clearEv+0x37)[0xb75f2fc7] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD1Ev+0x31)[0xb75f3101] /usr/lib/libdar.so.5000(_ZN6libdar9directoryD0Ev+0x22)[0xb75f3192] /usr/lib/libdar.so.5000(_ZN6libdar9catalogue8detruireEv+0x2d)[0xb75eb23d] /usr/lib/libdar.so.5000(_ZN6libdar9catalogueD0Ev+0x28)[0xb76014e8] /usr/lib/libdar.so.5000(_ZN6libdar7archive4freeEv+0x2d)[0xb767cfad] dar[0x806bc17] dar[0x8070c54] dar[0x805101a] /lib/libc.so.6(__libc_start_main+0xf5)[0xb72fc3d5] dar[0x8051191]

« First ‹ Previous 1 2 3 4 5 6 Next › Last »