Daniel Miller wrote:
Hi Josh,
Development on rdiff-backup has stagnated for the last while. I think
that this is attributable to several reasons:
* Andrew has dropped of the face of the earth, (he's working on
graduate studies, IIRC) and I've been busy with other things. Since
we're the two
Oops, meant to include the list.
---BeginMessage---
Daniel Miller wrote:
I'm looking forwarding to hearing your responses.
Are you sure about that? :)
Absolutely! I really would be excited about another project that uses
some of the same algorithms. As I said, more competition is
Two things:
1) The rdiff-backup project likely won't accept patches for features
that are platform specific. There are exceptions for OS-specific
filesystem metadata, but VSS doesn't fall into that category.
2) I've written a python extension module in C++ to implement VSS. Is
that something
The last time I checked, git didn't have great support for Windows.
Having fought to get CVS working there, I'd have a strong preference for
something with better Windows support. Has anyone on this list had
experience with Mercurial?
JoshN
Randy Syring wrote:
I saw a thread a month or two
wrote:
On Monday, April 5, 2010, 15:43:07, Josh Nisly wrote:
The last time I checked, git didn't have great support for Windows.
There's msysgit at http://code.google.com/p/msysgit/ and TortoiseGIT
for Explorer integration: http://code.google.com/p/tortoisegit/, and
as far as I can see
to develop a comprehensive test suite that runs on
all supported platforms. Code changes should be accompanied by tests.
Once the unicode changes are pulled back out, I've a fair number of
patches sitting in my own queue that can go in.
Feedback is welcome,
Josh Nisly
, it copies the new current_mirror file over from the
source, but doesn't remove the old current_mirror file from the
destination. This results in multiple current_mirror files, which
confuses rdiff-backup.
Josh Nisly
Kevin Fenzi wrote:
Greetings.
I have a user reporting an odd bug against
The impossible calculation may be gzipping the 16GB file -
rdiff-backup gzips deleted files to save space.
Josh Nisly
Whit Blauvelt wrote:
Hi,
Some followup:
Recopying the whole tree with --max-file-size 100 went very fast ( 1
min), left out the 3 files larger than that (including
Chris G wrote:
On Thu, Sep 03, 2009 at 07:08:28PM -0700, James Downs wrote:
On Sep 3, 2009, at 3:14 PM, Chris G wrote:
Is there any easy/obvious way of archiving old data out of home
directories so that rdiff-backup backups shrink? I suspect that there
If you delete data from
Are you saying that you have gotten this error? If so, do you have a
(preferably small) repository that demonstrates the problem?
I've never ran into this myself, so I obviously haven't looked into it,
but if someone has a repository that I could look at, I'd really like to
fix this.
One of my clients encountered an interesting bug in rdiff-backup - under
certain conditions, if a file changes while it is being backed up,
rdiff-backup throws an unhandled exception. The surface problem is that
rdiff-backup tries to read a Windows ACL from a file on linux, and dies
as a
Simon Hobson wrote:
Josh Nisly wrote:
You are correct in your analysis. Using rdiff-backup locally + rsync
to the NFS mount would certainly work.
Wouldn't that still leave the same fundamental problem - that using
NFS rather than rsync or rdiff-backup to access the backup storage
means
This error, I believe, means that the zipped file is invalid.
rdiff-backup doesn't actually control any of the zipping (it's all done
in Python libraries), so I suspect that it is a disk error.
JoshN
Billy Crook wrote:
I'm not sure if this is relevant or helps, but I was googling for
You appear to be using an unofficial version built from CVS. Is this the
case?
I plan to look into these errors at some point, but have not yet had a
chance to.
JoshN
Self biasresistor wrote:
Hello i want to know if there are other users of the 1.3.4 version on
a Linux ditrib on this
Actually, the can't retrieve ACL error messages are related. The error
you are seeing is a bug in rdiff-backup that happens when, for whatever,
reason, rdiff-backup is unable to retrieve ACL's (i.e. permissions
information) for a file. The solution is to simply log the error (which
we're doing
This is typical. rdiff-backup is checksumming each file's contents to
make sure that the file in the mirror is the same as the source file.
Since the data set is large, this will take a while. There really is no
way to tell rdiff-backup to skip files whose size matches, and I think
if you
Although the error message should be better, I believe that you are
calling rdiff-backup incorrectly. Depending on what you are trying to
do, you should either run:
rdiff-backup --test-server bac...@fileserver
or
/usr/bin/rdiff-backup bac...@fileserver::/var/exports/
-users-bounces+craig=plasmatronics.com...@nongnu.org
[mailto:rdiff-backup-users-bounces+craig=plasmatronics.com...@nongnu.org
] On Behalf Of Josh Nisly
Sent: Friday, 1 May 2009 1:58 AM
To: Craig Findlay
Cc: rdiff-backup
Subject: Re: [rdiff-backup-users] Crash in 1.3.3
CRC check failures typically
: In function ‘init_librsync’:
_librsyncmodule.c:477: error: ‘RS_DEFAULT_BLOCK_LEN’ undeclared
(first use in this function)
error: command 'gcc' failed with exit status 1
Looks like I'm still missing something. Any further ideas?
Thanks again,
~bob
Josh Nisly wrote:
You need to install the python-dev
tasks.
Cheers,
Craig
-Original Message-
From: rdiff-backup-users-bounces+craig=plasmatronics.com...@nongnu.org
[mailto:rdiff-backup-users-bounces+craig=plasmatronics.com...@nongnu.org
] On Behalf Of Josh Nisly
Sent: Friday, 1 May 2009 1:58 AM
To: Craig Findlay
Cc: rdiff-backup
Subject: Re
.html*,
/Josh Nisly/, 2009/04/08
But i dont understand how to use the patch even if i am sur it can
help me.
Its a python script so it must be used on the LInux side to rename the
strange folder names after the backup batch?
where can i found the attached files containing the script?
Thanks
Attached is a patch to support Unicode on Windows. This fixes support
for filenames with non-ascii characters, and paves the way for long
filename support. Also attached is a patch to prove the correct
behavior, which can be run on Windows or Unix.
Josh Nisly
#!/usr/bin/python
import os
Adrian-Bogdan Andreias wrote:
Hello,
I'm trying to do (almost) real time rdiff-backup by using inotify
kernel API. More specific, (a modified version of) lsyncd.
For this I think would need:
- rdiff-backup on single file. Since I have the modified files list,
there no point for rdiff to
I'd try putting quotes around the path of plink.exe. For example:
--remote-schema \c:\Program Files\Putty\plink.exe\
%s rdiff-backup --server
Josh Nisly
Orion wrote:
Hi everybody
I'm a user of rdiff-backup under Linux and I've tried today to set up a
similar configuration onto Windows
Orion wrote:
On Fri, 27 Mar 2009 10:56:44 -0500
Josh Nisly rdiffbac...@joshnisly.com wrote:
I'd try putting quotes around the path of plink.exe. For example:
--remote-schema \c:\Program Files\Putty\plink.exe\
%s rdiff-backup --server
Josh Nisly
Thanks, that seemed a good idea
Yes, rdiff-backup should use the data that is already on the server,
although if I remember correctly you will need to use the --force
parameter the first time.
JoshN
Friedrich Clausen wrote:
Hi All,
I am currently backing up some data via rsync but I want to start
using rdiff-backup
What happens if you try **System Volume Information (i.e. without the
slash)?
JoshN
Austin Roberts wrote:
I'm running the following command in a batch script (with some other
variables set):
rdiff-backup.exe -v5 --no-hard-links --force --print-statistics --remote-schema plink.exe -P %RPORT%
I've been seeing this consistently, unless I use the --no-hard-links
option. If you use that option, are unchanged files still incremented?
JoshN
Austin Roberts wrote:
Can anyone confirm that this behavior is abnormal for backing up
Windows to Linux? I've tried it on XP backing up to an
I've had very good success with doing this - I've actually never had a
problem. The first time you run it, you may get a warning like Warning:
access control list file not found., but rdiff-backup will
automatically create the file going forward, and you shouldn't see the
error again.
Josh
You are correct in your assessment. rdiff-backup is taking the
destination back to what it looked like at the end of the last
successful backup.
Josh Nisly
KJS wrote:
Anyone have any info on this??
Thanks
KJS wrote:
Hi,
I pressed 'ctrl c' to kill rdiff-backup which worked, now when i run
ACL's, so it's likely that the
update to libattr is the cause.
Josh Nisly
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au
Since we're talking about this anyway...
I operate a small business providing online backup service, centered
around rdiff-backup. I've built an installation and backup selection GUI
on top of it so that it's easy to use, and have rdiffWeb set up for easy
data restoration.
I'm not trying to
I know this isn't exactly what you asked for, but would a web interface
suffice for your needs? If so, then rdiffWeb (http://www.rdiffweb.org)
may be a good fit.
Thanks,
JoshN
Rodney Schuler wrote:
I have looked for a nice windows GUI for doing exactly this. I have
not found anything. Does
The problem this fixes is most evident when trying to back up an entire
drive e.g. C:\, but the same problem occurs whenever there is a trailing
slash in the path. The issue is that rdiff-backup has support for using
\ as a way of escaping characters in the path specifier. This is all
fine and
I don't know about the first problem (I though rdiff-backup on linux
handles it.) The second problem is because one of the underlying
libraries has a bug dealing with large (4GB) files. There is a patch
available that is typically applied on linux, but when I wrote the build
script, I simply
That's very possible. I'll try to look into it.
JoshN
weesterweb wrote:
I tried the same thing on Linux and it works fine. So it looks like there is a bug in windows build that restoring a single file or directory does not seem to work.
# rdiff-backup
I looked into this a bit today. Windows does throw a different exception
on long file names than unix (a WindowsError (derived from OSError,
derived from EnvironmentError), with the errno set to 206, which doesn't
map to anything valid on unix.) However, when I added a check for this
to the
Original Message
Subject:[rdiff-backup-users] Resuming initial backups
Date: Fri, 22 Aug 2008 09:24:23 -0500
From: Josh Nisly [EMAIL PROTECTED]
To: rdiff-backup rdiff-backup-users@nongnu.org
I have clients that back up large data sets over the internet
Andreas Neiser wrote:
Hej again,
Andreas Neiser wrote:
I figured out to edit the import lines in Time.py from:
import time,types, re, sys, calendar
import Globals
to:
time = __import__('time')
import types, re, sys, calendar
import Globals
The above should be done similary in the
I'm trying to implement support for removing a failed initial update.
One of the things that I need to do is remove the increments directory.
When I try to do this over a remote connection, the server throws a
security violation exception. However, we obviously need to delete
remote
Andrew Ferguson wrote:
On Sep 5, 2008, at 9:19 AM, Josh Nisly wrote:
I'm trying to implement support for removing a failed initial update.
One of the things that I need to do is remove the increments
directory. When I try to do this over a remote connection, the server
throws a security
The problem is because the versions are different - upgrade the remote
version to 1.2.0 or greater, and the problem should go away.
Josh Nisly
Erik Wickstrom wrote:
Hi all,
I kep getting the following traceback when trying to backup over ssh. The
client is Mac OS X (10.5) and the server
Maarten Bezemer wrote:
Hi,
On Fri, 22 Aug 2008, Josh Nisly wrote:
My question is this: couldn't rdiff-backup detect this and handle it
automatically? I've added code to my private branch that checks if there
is no current mirror and one or fewer error_log and mirror_metadata
files. If so
The windows executable does not depend on any python installation or
modules on the client system, only the modules on the system used to
build the executable.
Bottom line, Andrew will need to install the module (I think he already
has) and rebuild the executable.
JoshN
Shohn Trojacek
Andrew Ferguson wrote:
On Aug 2, 2008, at 6:55 AM, kartweel wrote:
I'm backing up from windows to linux over ssh using the new 1.2.0 on
both
client and server. Dispite my efforts and fiddling with clocks, it
stores a
diff for every file even when there are no changes. It isn't a big
deal, but
I'm not terribly familiar with the --include and --exclude options, but
the problems you're having don't seem to be specific to Windows. Why
don't you use
rdiff-backup --no-hard-links -v5 C:\DIRNAME
[EMAIL PROTECTED]::/root/windowsbackup ?
JoshN
Michael Crider wrote:
I got a little farther
Attached is the script that I've been using to build rdiff-backup. Just
run the script without arguments. It downloads and builds librsync and
rdiff-backup in a temp folder, and creates an output folder with
rdiff-backup.exe inside. The resulting executable does not need python
to be
it.
Hi Mico,
Thanks for giving rdiff-backup a try under Windows. As you discovered,
the current version still has some rough edges.
However, the latest version in CVS has four more Windows-specific
fixes, including one for the very issue you encountered. Josh Nisly
and Fred Gansevles have been hard
Andrew Ferguson wrote:
On Jun 26, 2008, at 10:48 PM, Josh Nisly wrote:
Fred Gansevles found some problems with the previous patch. Attached
is an updated one.
Josh Nisly wrote:
Attached is a patch that fixes any problems I know about with the
previous one, and includes several fixes
Fred Gansevles found some problems with the previous patch. Attached is
an updated one.
Josh Nisly wrote:
Attached is a patch that fixes any problems I know about with the
previous one, and includes several fixes by Fred Gansevles. It
serializes the ACL record to string in the RPath member
Actually, since the optimization affects determining whether the
destination needs checking, it speeds up all backups.
What is happening is that we are going through the rdiff-backup-data
directory, looking for current_mirror files. But for each file in the
directory, we instantiate an
Attached is a first-draft patch to add support for native Windows
permissions, including owner and ACLs.
First, let me say that Fred Gansevles is responsible for the most
interesting part of this - the code to load and save permissions
information to files. Thanks, Fred!
There are a couple
Here is another, simpler patch. This makes so that the makedist script
works on Windows, by using native python functions instead of unix programs.
The patch only uses the python functions if it's running on windows,
because some of the modules are not available in Python 2.2. When we
drop
Andrew Ferguson wrote:
On Jun 11, 2008, at 4:51 AM, Josh Nisly wrote:
Attached is a patch that implements the make_file_dict as described
above. Let me know what you think.
The patch for cmodule.c looks about right.
For rpath.py I have a concern: From earlier testing, I found
try/except
Josh Nisly wrote:
Andrew Ferguson wrote:
On Jun 6, 2008, at 12:44 PM, Josh Nisly wrote:
Armando M. Baratti wrote:
Fred Gansevles escreveu:
Hello,
I am currently working on a port for rdiff-backup that runs with
ActivePython.
It is a work in progress, but the first builds
Andrew Ferguson wrote:
On Jun 6, 2008, at 12:44 PM, Josh Nisly wrote:
Armando M. Baratti wrote:
Fred Gansevles escreveu:
Hello,
I am currently working on a port for rdiff-backup that runs with
ActivePython.
It is a work in progress, but the first builds of the _librsync.pyd
and C.pyd
://www.betterbe.com/rdiff
I'd like to know if more people think this port is useful.
Fred Gansevles.
[EMAIL PROTECTED]
There is (was?) someone else ( Josh Nisly - rdiffbackup at
joshnisly dot com) working on a native Windows ports of rdiff-backup:
http://lists.gnu.org/archive/html/rdiff
Unfortunately, I've found that the stat() function on Windows is pretty
broken - there are reports of it getting time stamps wrong, and it
doesn't support UNC paths, for example. Because of this, Python's stat()
implementation uses native Win32 functions. This patch copies some of
those
Charles Marcus wrote:
On 4/15/2008 8:14 AM, Josh Nisly wrote:
I've never seen a Windows program that even attempts to handle
hardlinks, so I'm not sure it's worth trying to handle them in
rdiff-backup.
Maybe you could check out DataSafe Backup?
http://sofgem.selfip.com/
This program
Andrew Ferguson wrote:
On Apr 13, 2008, at 6:24 PM, Josh Nisly wrote:
os.kill is not available on Windows, so there's no way from Python to
determine whether a process is running, without using the PyWin32
package. (We check to make sure that another rdiff-backup process
isn't already
rdiff-backup has a check when renaming a file to prevent it from
renaming over the same inode (rpath.py, around line 247). I started
porting this check directly to windows, but the more I think about it,
the less I'm sure that it's a good idea. On Windows, NTFS theoretically
supports hardlinks
Andrew Ferguson wrote:
On Apr 11, 2008, at 5:09 PM, Josh Nisly wrote:
Here's another patch for rdiff-backup on Windows. os.popen does not
work correctly on Windows, so this patch uses subprocess.Popen for
windows platforms.
Great. This patch and your previous one have been committed to CVS
Andrew Ferguson wrote:
On Apr 13, 2008, at 6:24 PM, Josh Nisly wrote:
Andrew Ferguson wrote:
On Apr 11, 2008, at 5:09 PM, Josh Nisly wrote:
Here's another patch for rdiff-backup on Windows. os.popen does not
work correctly on Windows, so this patch uses subprocess.Popen for
windows
Here's another patch for rdiff-backup on Windows. os.popen does not work
correctly on Windows, so this patch uses subprocess.Popen for windows
platforms.
I've tried to work around the issue the patches showing up as text by
tar'ing up the patch. Let me know if a different container format is
Andrew, the whole point of my patches is to make so that rdiff-backup
builds and runs without cygwin, i.e. natively. Knowing this might make
some of the below make more sense.
Andrew Ferguson wrote:
Thanks,
Josh Nisly
--- setup.py2008-01-03 09:36:49.0 -0600
+++ setup.py2008
Andrew Ferguson wrote:
On Apr 8, 2008, at 8:23 AM, Josh Nisly wrote:
Under a normal non-cygwin Windows build, there is no place to look
for the librsync library, so you have to specify a location
somehwere. It seemed that looking in the current directory was the
most generic place. Another
Andrew Ferguson wrote:
On Apr 8, 2008, at 10:23 AM, Josh Nisly wrote:
Sounds like a flag for libcmt.lib is unnecessary, then. However, you
shouldn't simply set lflags_arg to be that, but should append to
that array. (We don't want to overwrite anything the user may have set)
Did you mean
not to link in libcmt.lib.
Could someone with commit access please review these patches?
Thanks,
Josh Nisly
--- setup.py 2008-01-03 09:36:49.0 -0600
+++ setup.py 2008-04-02 17:58:36.984375000 -0500
@@ -40,6 +40,9 @@
libdir_list = [os.path.join(LIBRSYNC_DIR, 'lib')]
if '-lrsync' in LIBS
Oliver Hookins wrote:
On Mon Apr 07, 2008 at 19:34:25 -0500, Josh Nisly wrote:
I now have rdiff-backup building and performing local backups and
restores. This includes the initial backup, as well as subsequent
backups with changed files. I'm working on using Plink to back up
Patrick Nagel wrote:
Hi Josh,
Josh Nisly (Friday, 2008-04-04):
I'm attempting to make a native Windows port of rdiff-backup. I've
succeeded so far in building librsync and rdiff-backup's cmodules, as
well as fixing rdiff-backup's fs_abilities checks. What I'm running up
against now
? There's an old page on the wiki with some
high-level notes, but I couldn't find anything else.
Also, is Windows support something that's desirable enough that patches
for it would be accepted?
Thanks,
Josh Nisly
___
rdiff-backup-users mailing list
71 matches
Mail list logo
