On Mon, 2 May 2005, Clint Silvester wrote:
This is with 0.9.7, but I don't see it using that in any of the gcc
commands when it's compiling. The configure script says
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large
On Mon, 27 Jun 2005, Hunter Matthews wrote:
Were there any ideas on this? Can anyone else restore to Tiger?
your problem looks the same as bug #12949 ...
https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=12949
i see a patch for that bug
On Fri, 1 Jul 2005, Hunter Matthews wrote:
...
File /usr/lib64/python2.2/site-packages/rdiff_backup/librsync.py,
line 95, in _add_to_inbuf
new_in = self.infile.read(blocksize)
File /usr/lib64/python2.2/gzip.py, line 163, in read
self._read(readsize)
File
On Tue, 16 Aug 2005, Troels Arvin wrote:
Hello,
After upgrading to v. 1.0, I consistently get the following warning when
backing up:
Warning: ownership cannot be changed on filesystem at
/backup-data/backup3/hosts/HOSTNAME/_home/rdiff-backup-data
I'm backing up in to a directory owned
On Mon, 15 Aug 2005, john stultz wrote:
Something that I think would be helpful in the FAQ would be howto for moving
from using rsync to rdiff-backup, pointing out some of the subtle differences
between the arguments.
Currently I mirror nightly two partitions to a firewire disk using:
On Tue, 16 Aug 2005, Charles Duffy wrote:
http://arctic.org/~dean/rdiff-backup/unattended.html
Not workable in my situation:
- The instructions from the page in question require work to be done on
a per-server basis. I need to support tens to hundreds (and possibly
someday thousands) of
On Fri, 19 Aug 2005, Steve Clement wrote:
Also calling 1.0 stable is a bit poor as it seems we haven't tested it
enough :(
i dunno... i've been using 0.13.x since forever, and top of CVS since i
gained commit privs... and it's always been stable enough for me.
what you're seeing now is a
On Fri, 19 Aug 2005, Noah wrote:
Probably this error was caused because the first rdiff-backup session
into a new directory failed. If this is the case it is safe to delete
the rdiff_backup_data directory because there is no important
information in it.
yeah do what the error message
On Thu, 18 Aug 2005, Davy Durham wrote:
Is this serious? I get a few like this while backing up..
UpdateError var/log/secure Updated mirror temp file
./var/log/rdiff-backup.tmp.1685 does not match source
unfortunately there's always a race condition when backing up from a live
On Mon, 5 Sep 2005, Kingsley G. Morse Jr. wrote:
Hi,
What may have caused the following stack traces,
and how might they be fixed?
They seemed to happen at about the same time as
upgrading several Debian linux packages.
the upgrade was happening while rdiff-backup was running? did you
On Thu, 8 Sep 2005, Moritz Naumann wrote:
Warning: su: Permission denied
not sure where that's coming from, rdiff-backup won't invoke su on its
own.
I also tried removing /home/backupschizo/schizo/ and then retrying
rdiff-backup with the usage given by backupninja. However, this gave
On Fri, 14 Oct 2005, Carsten Lorenz wrote:
Since we want to backup one tera-byte of data this would last more than a
week.
i've never looked closely at why the first backup is so slow -- and i've
heard the report from lots of folks... i tend to use rsync for the initial
backup, and then use
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
you know, a segfault is very unlikely to be an rdiff-backup problem.
i'd be more tempted to blame the C compiler (which could be miscompiling
-backup, python, and gcc compiler, so
that I can reinstall again. Reinstalling the O.S. is not an option.
dean gaudet wrote:
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
On Tue, 25 Oct 2005, Piotr Nowacki wrote:
Hi,
I have been using rsync to copy data between remote sites,
so I have most of my data already copied.
Is there any way to create rdiff-backup metadata of existing bacup
done wiyh rsync, and then to continue using rdiff-backup to make
On Tue, 25 Oct 2005, Ben Escoto wrote:
It's a good idea, and one that someone else has suggested before. The
checksums would be stored in the mirror-metadata file. I don't even
think it would be hard to implement. And there could be a --verify
switch to go through the repository and make
On Fri, 4 Nov 2005, Fran Firman wrote:
At the moment I find a lot of false positives. ie a file is backed up
when it has not changed at all. When I was first reading about
rdiff-backup, and that it used rsync-lib, it seemed to be a side affect
of the rsync library. It had to do with the
On Mon, 7 Nov 2005, Murali Vadivelu wrote:
Another error!!
ListError private/var/launchd/0/sock [Errno 1] Operation not permitted:
'/private/var/launchd/0/sock'
maybe try with --exclude-sockets?
-dean
___
rdiff-backup-users mailing list at
On Sun, 6 Nov 2005, Blair Zajac wrote:
File /sw/lib/python2.4/site-packages/rdiff_backup/log.py, line 135, in
log_to_term
termfp.write(self.format(message, self.term_verbosity))
IOError: [Errno 35] Resource temporarily unavailable
you know there's no reason i can think of we would get
On Sun, 13 Nov 2005, Ben Escoto wrote:
Sheldon Hearn [EMAIL PROTECTED]
wrote the following on Sat, 12 Nov 2005 12:02:45 +0200
At the extreme, every object gets a serial number which is used as
its name in the backup store's filesystem.
...
But this is basically the way most backup
On Tue, 20 Dec 2005, Ben Escoto wrote:
dean gaudet [EMAIL PROTECTED]
wrote the following on Tue, 20 Dec 2005 00:08:26 -0800 (PST)
try http://arctic.org/~dean/rdiff-backup/backup-statistics
... give it the path to your mirror.
What do you think about adding this to the rdiff-backup
On Tue, 20 Dec 2005, Ben Escoto wrote:
dean gaudet [EMAIL PROTECTED]
wrote the following on Tue, 20 Dec 2005 14:06:16 -0800 (PST)
i have to exclude a ~2M inode subtree on my server because its inode
churn is way too high for my dsl + home /backup disk to accomodate.
(it's the http
On Wed, 18 Jan 2006, sim wrote:
On Wed, 18 Jan 2006, Peter Schuller wrote:
Often I would find it very useful to be able to say keep the N newest
snapshots and remove the rest, which is safer.
Peter,
This feature already exists in rdiff-backup. From the 'Time Formats'
section of the man
On Fri, 20 Jan 2006, Dr. Scott S. Jones wrote:
How do I get both to be the same versions? I run Debian 3.1 on both machines
and keep things updated with apt-get update/upgrade.
i'm guessing one of your boxes is stable and the other unstable...
unstable has 1.1.5 in it now... and the stable
On Fri, 20 Jan 2006, Brian C wrote:
Another option would be to uninstall rdiff-backup from both systems and
then just download 1.0.4 from the website and compile it on both
systems. The installation is extremely simple, but you can't use the
Debian version of librsync. So, as root do this on
On Wed, 25 Jan 2006, Troels Arvin wrote:
I'm backing up a Red Hat Enterprise Linux 4 with enabled SELinux support.
It seems that SELinux security contexts for files aren't backed up by
rdiff-backup.
I tought that SELinux's security contexts were implemented by extended
attributes (and that
On Fri, 27 Jan 2006, Troels Arvin wrote:
On Thu, 26 Jan 2006 16:48:42 -0800, dean gaudet wrote:
you probably need to install pyxattr package... i don't know the redhat
package name. install pylibacl while you're at it...
I already have the python-xattr and python-libacl packages
On Fri, 27 Jan 2006, dean gaudet wrote:
On Fri, 27 Jan 2006, Troels Arvin wrote:
On Thu, 26 Jan 2006 16:48:42 -0800, dean gaudet wrote:
you probably need to install pyxattr package... i don't know the redhat
package name. install pylibacl while you're at it...
I already have
On Thu, 26 Jan 2006, Charles Duffy wrote:
(Lacking this patch, btw, I was receiving security violations on the specified
method doing a simple restore of a backup specified with --restore-as-of
0B).
thanks... patch committed to 1.0.x and 1.1.x branches.
-dean
On Mon, 20 Feb 2006, Robert Yoon wrote:
How do i enable the remote schema to use blowfish ssh ?
Since it is faster.
i prefer to do that with .ssh/config... i go into lots of related details
here: http://arctic.org/~dean/rdiff-backup/unattended.html
Also by disabling the statistics
On Mon, 6 Feb 2006, Vadim Kouzmine wrote:
Let me summarize the information I've gathered during my tests, on two
platforms (Gentoo, Trustix 2.2) and different versions of python (2.2.3,
2.3.5, 2.4.2):
- on 3GHz P4 Xeon I get ~2MB/s steady transfer through ssh, on P4 3GHz
it's ~1.9MB/s;
-
On Wed, 1 Mar 2006, Brian C. Hill wrote:
ImportError: ld.so.1: /usr/pkg/python/bin/rdiff-backup: fatal:
librsync.so.1: open failed: No such file or directory
-
What am I doing wrong? Is an old Python installation (this
On Mon, 13 Mar 2006, Alex Meaden wrote:
Warning Security Violation!
Bad request for function: fs_abilities.get_fsabilities_readwrite
with arguments: ['destination', rdiff_backup.rpath.RPath instance at
0xb7a1b5ac, 1, None]
i'm pretty sure that's fixed in 1.0.something...
did you add
On Thu, 16 Mar 2006, Sebastien Maret wrote:
File /sw/lib/python2.4/site-packages/rdiff_backup/metadata.py, line 378,
in __init__
if compress and not rp_base.isinccompressed():
i think that line 378 in metadata.py needs to be:
if compress and rp_base.isincfile() and not
On Sat, 1 Apr 2006, Chris Wilson wrote:
Hi all,
On the machine where the disk filled up, I'm now getting the following
errors every time I run a particular backup:
Warning: Local version 1.0.1 does not match remote version 1.0.3.
Previous backup seems to have failed, regressing
On Sat, 8 Apr 2006, [EMAIL PROTECTED] wrote:
hello !
i like rdiff-backup very much - but - why the heck doesn`t it follow unix
commandline options standards ?
#rdiff-backup --help
Fatal Error: Bad commandline options: option --help not recognized
See the rdiff-backup manual page for
try with -v4 or -v5 maybe? it might show something more interesting...
btw there have been some recent bugfixes in librsync w.r.t. hanging on
large files... which doesn't sound like your problem, but is related.
-dean
On Tue, 11 Apr 2006, Jason Faulkner wrote:
Hi, I'm using rdiff-backup to
On Thu, 13 Apr 2006, roland wrote:
maybe my posting is relatet to this one ?
http://lists.gnu.org/archive/html/rdiff-backup-users/2004-09/msg00019.html
that was solved in 0.13.6... from the change log:
|** Serious bug fix **
|If a directory in the source
On Fri, 12 May 2006, Chris Wilson wrote:
in set_regress_inc
assert len(newer_incs) = 1, Too many recent increments
AssertionError: Too many recent increments
try running with -v5 or maybe even higher and see if you can figure out
where it's finding more increments than it's
On Mon, 15 May 2006, The Anarcat wrote:
Hello,
I have a problem running rdiff-backup over a directory which has a mode
of 0. The source directory is read as root so that poses no problem, but
the target directory is written as a regular user, so I get a:
File
On Mon, 15 May 2006, The Anarcat wrote:
/: write failed, file system is full
...
IOError: [Errno 28] No space left on device
Why the heck does it go write in /? /tmp? Why not use a tmp dir in the
target? And how can it use 130M of tmp?
that first error looks more like some general libc or
On Sun, 21 May 2006, Randall Nortman wrote:
I'm not sure where to look for this in the metadata.
look in the mirror_metadata file in the rdiff-backup-data subdirectory of
the target... you could probably gunzip and edit away the entry for that
file.
i think this one is fixed by later revs,
rdiff-backup requires a significant amount of extra space to fit its
filenames... at least until 1.1.x where ben has made it able to deal with
File name too long errors more gracefully... however i think based on
the bug reports i've seen here i'd hesitate to use 1.1.x.
-dean
On Sun, 21 May
On Mon, 22 May 2006, [EMAIL PROTECTED] wrote:
Hi:
--remove-older-than fails at some condition.
example procedure below:
[EMAIL PROTECTED] tmp]# mkdir foo
[EMAIL PROTECTED] tmp]# touch foo/a
[EMAIL PROTECTED] tmp]# rdiff-backup --version
rdiff-backup 1.1.5
[EMAIL PROTECTED] tmp]#
On Tue, 23 May 2006, Steve Clement wrote:
This is over a gigabit link SATA Raid 10 , conclude for yourselves.
i'm guessing you're saying the results are bad...
initial network backup is well known to be slow... in fact it's slow as
soon as you use separate processes, as can be demonstrated
On Wed, 24 May 2006, Steve Clement wrote:
dean gaudet wrote:
rdiff-backup --remote-schema '%s' src 'rdiff-backup --server'::dst
Well ssh is not the best file carrier, scp for instance is slow as...
but there is a HPN Patch:
i think you missed my point... remote rdiff-backup is slow even
On Wed, 24 May 2006, Mike Weisenborn wrote:
I have a fairly good-sized (34G) backup set of which 17G or so is the
current data, and another 17G is the last 30 days of incrementals.
I'm trying to create a snapshot of this data in another location by doing
this:
rdiff-backup -r now
On Wed, 24 May 2006, Adam Lazur wrote:
ValueError: invalid literal for long(): 22714811 ModTime 11037487348i55id 1003
that looks fairly well corrupted...
Is it time to perform surgery on the metadata file? I'm cool with
blowing away portions of the tree to save my backup... but I'd rather
On Thu, 25 May 2006, Kannarat Chiemchitvanicha wrote:
However, it seems like I have a problem with the 32-bit/64-bit mismatch and
I need to relink the library in the 64-bit mode.
yes, the .so must match the architecture of the python binary.
-dean
On Thu, 25 May 2006, Niki Hammler wrote:
1.) Is there a way to save old increments to another directory?
nope.
2.) If for example would like to restore a file 365 days. Is it correct that I
have to apply all diffs since then?
yep. one of the commonly requested features is the ability to
On Mon, 29 May 2006, Douglas Bollinger wrote:
Anyone see this and is there an easy workaround?
this sounds like an older bug... what version are you using?
-dean
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
On Fri, 2 Jun 2006, Douglas Bollinger wrote:
On Wed, 31 May 2006 07:59:26 -0700 (PDT)
dean gaudet [EMAIL PROTECTED] wrote:
On Mon, 29 May 2006, Douglas Bollinger wrote:
Anyone see this and is there an easy workaround?
this sounds like an older bug... what version are you using
On Wed, 7 Jun 2006, Chris Fanning wrote:
I've got a problem running rdiff-backup as a cron job.
do you get any mail from cron? usually you should get some mail with
stdout/stderr in it... i'm guessing it would help diagnose this...
-dean
___
On Sun, 11 Jun 2006, Douglas Bollinger wrote:
On Sat, 10 Jun 2006 13:07:46 -0700 (PDT)
dean gaudet [EMAIL PROTECTED] wrote:
snip
rdiff-backup, for better or worse, does a chmod on the directory while
it's operating. it has no problems with the directory... i even tried
removing
rdiff-backup won't handle this cleanly. it will treat all the newly named
files as new and keep deltas deleting the old names... so yeah it'll
double your space requirements until you age the old deltas.
the inode is used for hardlink detection only... not renaming
unfortunately.
mind you
i'd try something like:
find mirror -type f -print0 | xargs -0 touch -d yesterday
that might cause rdiff-backup to recompare everything and set the
timestamps appropriately...
if that doesn't work then try uncompressing the latest mirror_metadata
file and using perl or something to set the
for this one we'll probably need strace output... suitably trimmed to show
what it's trying to do with the problem file and possibly surrounding
directory.
can you reproduce with a small test case?
what rdiff-backup version? there have been some nfs-related fixes... in
1.0.3 for example.
On Fri, 14 Jul 2006, Jes Kasper Klittum wrote:
raise ConnectionReadError(Truncated header string (problem
rdiff_backup.connection.ConnectionReadError: Truncated header string (problem
probably originated remotely)
the Nonetype stuff is misleading... it's the stuff here at the end of
the
On Tue, 18 Jul 2006, Jes Kasper Klittum wrote:
the Nonetype stuff is misleading... it's the stuff here at the end of
the error message which has a hint.
any reason the net would drop out? is the backup over dsl? keep-alives
set too low or some other form of timeout kicking in?
On Wed, 19 Jul 2006, Jes Kasper Klittum wrote:
There is a switch between the two servers. Rsync never fails though? It seems
to happen at an hour stroke - say 12.04 PM 6.08 PM and so forth. I was
wondering if this could happen in conjunction with a cron job being run. If
load is high or
On Wed, 19 Jul 2006, Jes Kasper Klittum wrote:
none of that seems very likely...
can you attach strace to the rdiff-backup process on the remote host?
strace -o tracefile -p $pid ... hopefully there'll be some hint at the
very end. if that doesn't help then also try figuring out
On Thu, 20 Jul 2006, Jes Kasper Klittum wrote:
Den 19/07/2006 kl. 19.53 skrev dean gaudet:
assuming that you were tracing the remote rdiff-backup then it appears to
be getting an EOF on stdin... which makes me think there's something going
on in the transport layer... not sure what
On Thu, 20 Jul 2006, Jes Kasper Klittum wrote:
10:15:10.543684 IP backupserver.com.59297 remote-server.com.99: F
82592624:82592624(0) ack 39621297 win 10064 nop,nop,timestamp 1153104691
2127151431
10:15:10.583398 IP remote-server.com.99 backupserver.com.59297: F
39621297:39621297(0) ack
there's several threads like this in the archive...
unfortunately there's no perfect solution... it needs improvement in the
code. (patches welcome :)
note that rdiff-backup at best is going to need 2x the storage space for a
large file -- otherwise it would be modifying the file in-place and
On Fri, 21 Jul 2006, Peter Valdemar Mørch wrote:
Karjala karjala_lists-at-karjala.org |Lists| wrote:
The last-modified date on a directory shows when there has been any change
in a file inside that directory or any of its subdirectories.
That assumption is not correct. Not with reiser-fs
On Sun, 23 Jul 2006, Charles Duffy wrote:
I'm running backups in such a way that rdiff-backup --server is being run
with uid and gid backup. I want to be able to give users who are allowed to
run restores membership in the backup group, and arrange permissions such that
this is sufficient to
On Mon, 24 Jul 2006, Jes Kasper Klittum wrote:
Den 21/07/2006 kl. 18.46 skrev dean gaudet:
On Fri, 21 Jul 2006, Jes Kasper Klittum wrote:
Attached is the last 99 lines of the v9 log, after it failed 2 hours and
39
minutes after initiation. I don't really see anything wrong
On Mon, 24 Jul 2006, Chris Connett wrote:
Hello,
http://lists.nongnu.org/archive/html/rdiff-backup-users/2006-01/msg00070.html
I saw a few archived mails that exactly describe the problem I'm
having now, but the problem doesn't seem to have gone away. There was
talk of fixing it, but
On Tue, 25 Jul 2006, Giacomo A. Catenazzi wrote:
Hello
For remote backup, after the normal backup, I delete the older
files, with two policies 15 days, but max. 5 changes:
echo
rdiff-backup --remove-older-than 15D
[EMAIL PROTECTED]::/home/pix-backups/orion2
echo
ah yeah that's fixed only in CVS... hasn't been released.
you can grab the cvs repo if you want... only reason it hasn't been
released is because ben has been otherwise busy. i've been using it for
months.
http://savannah.nongnu.org/cvs/?group=rdiff-backup
you want to add in a -r r1-0 option
On Thu, 27 Jul 2006, Giacomo A. Catenazzi wrote:
dean gaudet wrote:
ah yeah that's fixed only in CVS... hasn't been released.
you can grab the cvs repo if you want... only reason it hasn't been
released is because ben has been otherwise busy. i've been using it for
months
On Sun, 30 Jul 2006, Chris Connett wrote:
Thanks for your comments. Jumping into a new code base, I was pretty
sure I wouldn't get it right my first shot. I looked for the callers
when writing this, but I took the assert to mean temp files should
always be local, which apparently isn't the
On Fri, 4 Aug 2006, Maarten Bezemer wrote:
This made me think about something related: what happens if the tree
you're backup up contains an rdiff-backup-data directory? Will it be
escaped? Will it be ignored? Will it be used and screw up the whole thing?
danger danger. you'll be unhappy if
On Thu, 24 Aug 2006, Keith Edmunds wrote:
On 08/23/2006 9:18:37 PM +0100
Sebastien Maret [EMAIL PROTECTED] said:
When this occurs, the next backup fails because rdiff-backup believes
that there is still a process running, although it is not the case. Is
this a bug in the way
On Sat, 26 Aug 2006, roland wrote:
AttributeError: RPath instance has no attribute 'inc_compressed'
The hint at
http://lists.nongnu.org/archive/html/rdiff-backup-users/2006-03/msg00038.html
has helped here.
i think last i looked at the code there i couldn't quite figure out if my
On Mon, 9 Oct 2006, Seather wrote:
Hi there,
When I run an rdiff-backup --list-increment-sizes, the output seems to be
reversed. Am I perhaps missing something or confused about how this works? In
my output that I have pasted below, the Cumulative size field decreases as
the date
On Tue, 31 Oct 2006, Keith Edmunds wrote:
Ben, are you still reading this? Dean?
i'm here...
rdiff-backup just hasn't been at the top of my list for a while. mostly
because i have a setup which works and there's a zillion other things with
higher priority right now.
i'm still using
On Wed, 1 Nov 2006, J. Norment wrote:
I'd like to clear out the repo at the end of the month and start with a fresh
one... is the best way to do this just to delete everything under the
rdiff-backup-data path?
yes, and then you have to add --force to the next invocation of
rdiff-backup so
On Sat, 4 Nov 2006, Yeroc wrote:
dean gaudet-2 wrote:
On Tue, 31 Oct 2006, Keith Edmunds wrote:
[...]
but this shouldn't stop anyone else from contributing patches.
[...]
You're right that this shouldn't stop anyone else from contributing patches
but the problem is that without
thanks... applied to both trees.
-dean
On Sat, 4 Nov 2006, Andrew Ferguson wrote:
Hi,
Some Unix systems (at least the *BSDs and Mac OS X) set the permission
bits on symbolic links to 777 - umask at link creation. This is
different from Linux, where all symbolic links are mode 777.
This
applied to cvs HEAD only.
am i right that the 1.1.x tree is the preferred tree for OSX users? (i.e.
i shouldn't bother applying OSX patches to 1.0.x tree?)
-dean
On Thu, 17 Aug 2006, Andrew Ferguson wrote:
Hi,
The attached patch against the rdiff-backup CVS adds support for
preserving
On Sat, 29 Apr 2006, Andrew Ferguson wrote:
Mac OS X 10.4 introduced generic extended attributes to the HFS+
filesystem. By using the xattr Python module from
http://undefined.org/python/ and the attached patch, rdiff-backup can
handle backing up these new attributes. The patch is against the
can you provide a patch against current cvs head?
-dean
On Sat, 2 Sep 2006, [EMAIL PROTECTED] wrote:
Good evening,
i came across http://savannah.nongnu.org/bugs/?func=detailitemitem_id=16447
today.
bug #16447: manpage not in sync w/ current options
i took a deeper look into that,
this seems reasonable -- but your mailer seems to have damaged the
patch... could you refresh against cvs head and resend?
thanks
-dean
On Tue, 16 May 2006, The Anarcat wrote:
[EMAIL PROTECTED] wrote:
Maybe we should check fail/success when looking in that directory and if
it fails,
hi... i figure it can't hurt too badly if i commit patches which i've only
read and not tested. can't be worse than the current situation.
i've committed a handful i found in my mailbox and in the bugs/patches
tracker.
if you have patches you've been using/tested for a while and would like to
On Sat, 4 Nov 2006, Andrew Ferguson wrote:
dean gaudet wrote:
hi... i figure it can't hurt too badly if i commit patches which i've only
read and not tested. can't be worse than the current situation.
i've committed a handful i found in my mailbox and in the bugs/patches
tracker
On Sun, 5 Nov 2006, Andrew Ferguson wrote:
Blair Zajac wrote:
diff -Nur rdiff-backup-cvs/rdiff_backup/rpath.py rdiff-backup-
symlink-perms/rdiff_backup/rpath.py
--- rdiff-backup-cvs/rdiff_backup/rpath.py 2006-01-13
00:29:47.0 -0500
+++
seems like i figured out all the details for making a release.
except i don't run redhat/fedora anywhere, so i didn't make an rpm.
instead i placed the spec files into the release tarball, so folks can
build their own.
enjoy!
-dean
New in v1.1.6 (2006/11/11)
--
Man
and to go along with the 1.1.6 release here's a new stable 1.0.5 release.
http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.0.5.tar.gz
-dean
New in v1.0.5 (2006/11/11)
--
Fix a traceback due to an off-by-1 error in --remove-older-than nB.
Fix a security
fixes the OSX showstopper in 1.1.6.
http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.1.7.tar.gz
i have to admit, i haven't tested these releases... but i'm still of the
opinion it's better for me to commit / release than it is to just let
things stagnate :)
-dean
New in v1.1.7
as i mentioned at some other point when this was asked... i'm really not
100% certain that change is the right change... that's why i never applied
it to cvs.
maybe someone could look at it more closely?
-dean
On Wed, 15 Nov 2006, Gordon Rowell wrote:
Gordon Rowell wrote:
Bumping this
sounds like the bug is that rdiff-backup decides there's a metadata change
and stores an almost-empty .diff.gz file even though it's not required.
even though the metadata change is innocuous...
seems like it would be possible to at least avoid the almost-empty patch
file when there is a
commited, thanks.
-dean
On Thu, 16 Nov 2006, Gordon Rowell wrote:
- Adjust URLs
- Add changelog entries
It's a pity there is an Epoch: 0 header in the SPEC files as an Epoch of zero
outvotes no Epoch. I'd be tempted to delete those headers and let RPM
versioning work normally. However,
On Sat, 18 Nov 2006, Andrew Ferguson wrote:
dean gaudet wrote:
sounds like the bug is that rdiff-backup decides there's a metadata change
and stores an almost-empty .diff.gz file even though it's not required.
even though the metadata change is innocuous...
I think there could
On Sat, 18 Nov 2006, dean gaudet wrote:
yep -- but we could store an actual 0-length file instead... so we're not
wasting an entire disk block on many filesystems. better to name it
.nodiff or something else so we can distinguish between an incompletely
written .diff.gz and a file
On Thu, 16 Nov 2006, Gordon Rowell wrote:
Has anyone looked at storing symlink metadata separately for filesystems
which don't support symlinks? In particular, when backing up to a CIFS
fileystem. This currently logs a SpecialFileError, which is not surprising.
yeah it would be desirable to
as a one time hack, if you want to reduce the network bandwidth required
to move the 1GB file you could hardlink the oldfile to the newfile (and
leave the oldfile around for now) and then do a backup... rdiff-backup
will detect the hardlink and just hardlink the destination file in the
mirror
On Fri, 29 Dec 2006, Andrew Ferguson wrote:
dean gaudet wrote:
btw -- adding two syscalls per symlink creation is a bit of a waste for
platforms where it doesn't matter. any chance you'd consider adding a
test to fs_abilities and conditionalizing on it?
Dean,
I have added
i wonder why i don't have this problem on million+ inode systems... i've
had it working with python2.3 before too (although i'm using 2.4 now)...
i'm still on 1.0.x.
is there a 32/64-bit mismatch between your hosts? any chance there's some
bug in that?
-dean
On Sat, 13 Jan 2007, Charles
On Fri, 26 Jan 2007, Marc Dyksterhouse wrote:
http://www.visiwave.com/download/rdiff_backup/rpath.py.patch
can you provide more information on why this is necessary? i'm assuming
it's because cygwin/windows can't do an fsync in some situation...
would it be possible to put another
1 - 100 of 131 matches
Mail list logo
