On Mon, 14 Jan 2008, Dave Kempe wrote:
Lexje wrote:
I'm completely new to rdiff-backup.
I'm trying to backup a complete server over the internet. Is it possible to
pause, stop / restart rdiff-backup? (To free up / respect
bandwith limitations)
You could do a Ctrl-Z and then start it
On Thu, 30 Aug 2007, Jon Kolb wrote:
Matthew Flaschen wrote:
Jon Kolb wrote:
After poking around for a while, I discovered that on encfs/sshfs
(or perhaps fuse in general), os.rename fails with Operation not
permitted if the destination file already exists.
That sounds like a bug
Andrew has been busy. Time for a new release.
-dean
New in v1.1.13 (2007/08/12)
---
Properly pickle QuotedRPaths. Fixes regress operation on quoted filesystems.
Closes Savannah bug #20570 reported by Morgan Read. (Andrew Ferguson)
Warn if can't write extended
1.1.x in theory protects itself from multiple writers to the same
destination (i say theory because i haven't tested it).
1.0.x does not protect itself from multiple writers.
-dean
On Sat, 11 Aug 2007, Matthew Flaschen wrote:
What will happen if the same rdiff-backup sources and destinations
i see Andrew has been quite busy! excellent.
he mentioned he is considering promoting 1.1.x to stable. what i'd really
like to see is some testing of 1.0.x - 1.1.x upgrading on existing repos.
also, can a user who has troubles with 1.1.x revert to 1.0.x?
could some people install 1.0.x and
fwiw backing up databases with rdiff-backup is unlikely to produce a
properly restorable database (ditto rsync or even cp)... unless you're
stopping your database server while the backup runs... or using a
filesystem or volume snapshot feature.
-dean
On Thu, 2 Aug 2007, Joost van den Broek
On Sun, 29 Jul 2007, micah wrote:
This time Debian stable (etch) has the rdiff-backup stable version 1.1.5, and
1.1.5 is not a *stable* version, it's an *unstable* version.
http://www.nongnu.org/rdiff-backup/
-dean
___
rdiff-backup-users mailing
On Thu, 12 Jul 2007, Andrew Ferguson wrote:
- Handling CIFS mounts that don't do symlinks, this is Savannah Bug
#20342 (https://savannah.nongnu.org/bugs/?20342). Does anyone have any
thoughts about what we should do? I am leaning towards creating a dummy
file.
we already do dummy files for
ben has traditionally maintained backwards compat for the on-disk storage,
but not necessarily for the network protocol. i think you can assume
we'll attempt the same going forward.
yeah i know it's a hassle in mixed setups, and if someone wants to learn
the net layer well enough to provide
On Wed, 6 Jun 2007, Ilari Scheinin wrote:
I am running rdiff-backup with the --exclude-sockets option, but I am
still getting this kind of error for every socket:
ListError private/var/launchd/0/sock [Errno 1] Operation not
permitted: '/private/var/launchd/0/sock'
Good catch! If
look at fail2ban for the ssh probes... there are similar packages for
non-linux as well. (although it shouldn't be too hard to port.)
someone pointed out --remote-schema already... what i tend to prefer for
ssh is to make up fake hostnames in .ssh/config. (see
it prunes the entire directory and its subdirectories. patches to clarify
the man page are welcome.
-dean
On Tue, 5 Jun 2007, [EMAIL PROTECTED] wrote:
Hi there,
how does this new option behave in 1.1.10? it is not clear from the man page.
does it only exclude directories or also
wait a day and try again? ;)
perhaps find, xargs and touch are your friends:
touch /tmp/now
find /backup/location -type f -newer /tmp/now -print0 \
| xargs -0 touch
-dean
On Fri, 18 May 2007, Dan Muresan wrote:
Hi all,
a couple of days ago, my system clock was way off into the
On Sat, 19 May 2007, Dan Muresan wrote:
Hi,
wait a day and try again? ;)
the broken timestamp is a few *months* off into the future, so you must mean
wait a couple of months and try again in this case... Right? Which is not
practical...
perhaps find, xargs and touch are your
On Sat, 19 May 2007, Dan Muresan wrote:
yeah you're right, a lot more editing is required... sorry, you'll either
need to dive in and do all the editing or ditch your rdiff-backup-data
subdir and lose the history (and start the next backup with a --force so
it'll create that subdir).
please post another e-mail.
FYI: I tried to get OpenSUSE factory to update to 1.1.10, but they
said no because it was a devel/unstable release.
Thanks
Greg
On 5/13/07, dean gaudet [EMAIL PROTECTED] wrote:
i realised i'd moved my rdiff-backup mail folder after linux-kernel in my
tab list
i realised i'd moved my rdiff-backup mail folder after linux-kernel in my
tab list... and hadn't got past linux-kernel in months. oops.
better late than never.
as before, i haven't tested it (i'm still using 1.0.5), i'm just releasing
it because there was a request for a new release.
-dean
without knowing anything about PITR... have you actually tried restoring
from rsyncs in this situation? knowing what i do about the rdiff/rsync
algo i'm having a hard time imagining any such feature truly working over
*all* differences. i can imagine how PITR works, and the problem i see is
On Thu, 15 Mar 2007, Sean Bandes wrote:
I need to work with the tar.gz version but
http://savannah.nongnu.org/download/rdiff-backup/ yeilds nada.
anyone have 1.0.5 in tar.gz?
dunno why you're not seeing it ... when i went to your url i see it:
excellent, i've wanted this feature... i'll apply it next time i'm running
through patches. any chance you could do a 1.1.x port as well?
thanks
-dean
On Thu, 15 Mar 2007, Jeff Strunk wrote:
I have a small contribution to make in the form of a simple selection
function.
My company has
On Thu, 8 Mar 2007, Jeff Strunk wrote:
Any ideas on increasing localhost performance? Is that the way it should be?
use sudo with NOPASSWD.
search for localhost:
http://arctic.org/~dean/rdiff-backup/unattended.html
-dean
___
rdiff-backup-users
i don't think sending a SIGCONT is a good idea... perhaps the other backup
was SIGSTOPped for a good reason.
the code should be using signal 0, not signal.NSIG. could you test that
and resubmit? a signal of 0 on unix causes all the error checking to be
performed but no signal is actually
On Sun, 4 Feb 2007, [EMAIL PROTECTED] wrote:
ok, this is not a real issue because we should never do such ugly file
deletion in the repository, but iirc, several users have requested
remove files from repository as a feature.
you can delete the file... gunzip the metadata file, remove the
this backup for a while because of this, started a new
repository because of this.
-Ursprüngliche Nachricht-
Von: dean gaudet [EMAIL PROTECTED]
Gesendet: 04.02.07 21:37:14
An: [EMAIL PROTECTED]
CC: rdiff-backup-users@nongnu.org
Betreff: Re: [rdiff-backup-users] handling
On Mon, 29 Jan 2007, Marc Dyksterhouse wrote:
These two still need to be applied:
http://www.visiwave.com/download/rdiff_backup/fs_abilities.py.2.patch
http://www.visiwave.com/download/rdiff_backup/rpath.py.patch
both are now committed... thanks!
-dean
On Sun, 28 Jan 2007, Andrew Price wrote:
On 28/01/07 02:58, dean gaudet wrote:
patches welcome. include a man page patch as well.
Here's a first attempt, using backslash as the escape character:
http://andrewprice.me.uk/dropoff/glob_escaping.diff
http://andrewprice.me.uk/dropoff
this should let the cygwin folks test out all the recent patches.
-dean
New in v1.1.8 (2007/01/29)
--
Cygwin generates EACCESS on fsync -- so accept it rather than dieing.
(Marc Dyksterhouse).
Add FilenameMapping.set_init_quote_vals security exception.
(Marc
rdiff-backup is covered by the GPL. there's a file COPYING at the root of
the tarball which describes your rights.
in particular you have to provide source code for changes you make to
rdiff-backup.
-dean
On Mon, 29 Jan 2007, Daniel wrote:
hi to everyone,
I've recently discovered
here's a new release to fix the merge error in 1.1.8. enjoy!
-dean
New in v1.1.9 (2007/01/29)
--
Cygwin generates OSError when changing permissions on partitions.
(Patch from Andrew Ferguson.)
Fix fs_abilities.py patch error with set_escape_dos_devices.
(Marc
On Mon, 29 Jan 2007, Marc Dyksterhouse wrote:
Dean,
I looked into what was happening with fsync under cygwin. Turns out fsync
returns EACCES for any file so I added that to the except clause to prevent
the exception from being re-raised. After fixing that, a few more exceptions
where
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
On Mon, 22 Jan 2007, Dave Howorth wrote:
Andrew Price wrote:
On 12/01/07 11:57, Andrew Price wrote:
I'm using --include-globbing-filelist. If I wanted to specify a file in
a file list that has [] in the file name, e.g. myfile[foo].txt, how
would I escape the square brackets so that
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, 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
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 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
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,
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
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
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
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
+++
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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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
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.
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
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
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 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 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 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 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 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 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, 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 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 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
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 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
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 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 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 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
1 - 100 of 131 matches
Mail list logo
